I've managed to never use migrations before. Instead I've just used a graphic schema design app like Toad Data Modeler, to draw up the db and spit out the sql. So, wanting to give more of the "rails way" a try, I'm now looking into migrations.
I have a couple of questions off the bat, and would love to hear some opinions: 1) Do you find it better to organize migration files on a file-per-model basis, or rather to put all the migration lines for some particular functional change into one file even if that involves multiple models? Or are there other useful ways to organize? 2) How do you view/browse your database design? SQL dump of the db? Use schema.rb as the definitive reference? 3) No support for foreign key constraints? Really? There is the "execute" method, but that cracks open the door to the migration file being database specific. Another concern is that apparently the schema.rb file (the supposed single file that represents your current db state with all migrations run) will ignore the foreign key constraints. So, it looks like *not* having foreign key constraints in your db is considered the rails way, but it still seems like a good safety net at the least. And what if a non-rails-app wanted to use the db as well? Not sure I want to give up that db-level protection. In the real world, do the heavy rails users go ahead and leave out the foreign key constraints? -glenn -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
