ORM Designer and MySQL Workbench comparison

Both MySQL Workbench and ORM Designer are entity relationship diagram modeling (ERD) tools but the difference is in the concept behind. MySQL Workbench provides tight integration with MySQL. ORM Designer on the other hand relies on the underlying ORM framework. Let us introduce you to John, who would be our anonymous tester. John is starting a new PHP online store based on MySQL.

John developing a single online store

John doesn't use any ORM framework and he uses standard PHP MySQL API. John chose to use MySQL Workbench for this project, because he would benefit from MySQL Workbench database connectivity. He can model ERD, create users and export database schema directly into MySQL database. He can define views and stored procedures on one place. MySQL Workbench is a wise choice in this case.

John developing multiple online stores

John would like to sell his online store to more customers, so he decided to split the project into plugins. All stores would need some core functionality and then would be extended through optional plugins (related products plugin, wishlist plugin, payment modules etc.). If a customer needs some unique feature or hack a plugin, John would override the plugin methods or extend plugin functionality.

John decided to use ORM Designer because he would use its plugin support. He doesn't want to create ER diagram for each project. With ORM Designer he can split the database model into separate files for each plugin and then select which plugins are used in the project. He doesn't have to reorder the tables each time or make changes in all the projects if there is a change in a plugin. He also realized he can generate a simple CRUD (CReate Update Delete) backend interface out of the XML definitions stored by ORM Designer.

In this case we made John choose ORM Designer, but we admit others might choose otherwise. If you choose ORM Designer, you loose the possilbility to work directly with MySQL database. But if you go with MySQL Workbench you have to create the ER diagram for each project and maintain them separately.

John developing multiple online stores with ORM framework

John made some Googling and found Symfony and Doctrine (Zend Framework or Propel) and realized it could make his life a lot easier. He went through the documentation and started coding database schema. But writing schema for 50 tables was no fun and after making many typos and looking back into documentation every 5minutes for a definition he decided to go back to Google.

He found out he could convert database schema from MySQL Workbench into Doctrine definitions, but he would have still make some fixes, change relation names and write all the behaviors by hand. And still no plugin support. So he chose ORM Designer instead. With ORM Designer he imported his Symfony project with some community plugins he found. Within 2 minutes he made some changes to the automatic layout of tables imported from plugins and he was ready to start adding his own tables. John created some extra plugins for his online stores and created the tables he needed. Then he changed relation names and still within the user interface defined Doctrine behaviors and defined MySQL engine options for the plugins (InnoDB + UTF8 character set). He was happy to see he could build the classes without any hitch because there was no typo in the schema files.

Sum up

We are aware of ORM Designer shortcomings when it comes to database management. We leave this to the ORM framework which makes much better job, because it provides multiple database support out of the box and it's a good practise to leave this task to the ORM framework.

It doesn't matter if you use Propel or Doctrine, Zend Framework, Symfony framework or no web framework at all. You can benefit from full ORM framework support (specific data types, behaviors and vendor options) and programming practicies like plugins and versioning systems.