hi. 1. when you start from workbench you deal with tables, rows. after it you have to use reverse engineering for build schema.yml
2. when you start from schema.yml, you deal with objects here and after it you ask orm to build db based on this value-objects. both cases have self benefits and self probs. with 1-st case you can use some extended features of db. here is few possible probs: 1. orm maybe don't support such features, as they are db specific 2. orm have another conventions about types (4ex boolean or enum types). 3. from 1-st and 2-nd no way to migrate smoothly to another db with 2-nd case you can use features of orm and don't really care about how it was been saved/retrieved to db here is probs too: 1. generated db probably not optimal, as it don't use any db specific features (4ex m-m relations have additional column id in ref table) 2. no way to work with structure of db in visual way so i think it's matter of taste. if you prefer to go in relational way (or you like to find&fix bugs in an orm), go with 1-st case. if you prefer to go in object-oriented way(or you like to switch between sqlite-mysql-oracle based on day of week), go with 2-nd case. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
