I tried to create an invoicing system with symfony 1.4. It did not work out well as the database design contained some complex composite keys which were not possible to be mapped properly in doctrine that is bundled with symfony 1.4.
I tried to work around by creating the database first, and then generating the schema. But, if I use the same generated schema and created the database, some extra unnecessary constrains were generated. These constrains made the database design useless. After trying a couple of time, I lost my faith in doctrine, and just gave up.
See my post on doctrine and composite keys to see the design which caused the problem.
I heard that symfony-2 has a better support for the composite keys, and tried it out. Again, it did not work out well.
Then, after some searching, I learned that to properly use an ORM, I should start with a class diagram. ORM should persist it to the relational database. I should not go the other way around, which is, creating the relational db structure and mapping it to the class diagram. So, I tried the above db design in the OO context, and below is the initial draft I could quickly produce. This diagram sees simpler and natural to put into action with an ORM.
A complex problem to be solved in one perspective, can be a very simple one in another perspective. Finding the right tool, if it seems hard, then consider finding the right perspective to solve the problem.
I tried to work around by creating the database first, and then generating the schema. But, if I use the same generated schema and created the database, some extra unnecessary constrains were generated. These constrains made the database design useless. After trying a couple of time, I lost my faith in doctrine, and just gave up.
See my post on doctrine and composite keys to see the design which caused the problem.
I heard that symfony-2 has a better support for the composite keys, and tried it out. Again, it did not work out well.
Then, after some searching, I learned that to properly use an ORM, I should start with a class diagram. ORM should persist it to the relational database. I should not go the other way around, which is, creating the relational db structure and mapping it to the class diagram. So, I tried the above db design in the OO context, and below is the initial draft I could quickly produce. This diagram sees simpler and natural to put into action with an ORM.
A complex problem to be solved in one perspective, can be a very simple one in another perspective. Finding the right tool, if it seems hard, then consider finding the right perspective to solve the problem.
1 comment:
another way to overcome the composite foreign key is to add a multi-column index, and declare it as unique
Post a Comment