On 7/15/11 4:30 PM, Glenn Little wrote: > 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?
By functional change. The filenames are prefixed with timestamps, so file-per-model wouldn't really help with sorting, if that's what you're thinking. > > 2) How do you view/browse your database design? SQL dump of the db? > Use schema.rb as the definitive reference? Yes, current best practice is to keep a schema file that is the authoritative record of your DB. Rails provides both options (http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you). IMO schema.rb is the most pleasant form. > > 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? AFAIK, yes, most Rails users don't bother with foreign key constraints. AR already provides a lot of data integrity stuff that we don't trust the DB to do, and duplicating one of those parts at a lower level feels pointless. And if you're worried about being database-specific, in some sense foreign key constraints *are* database-specific. If you really need the key constraints for other codebases or your own comfort, I believe https://github.com/matthuhiggins/foreigner is popular. Ian -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
