I have observed that in a few projects (for larger enterpriseish type companies) that folks prefer to use raw SQL in the migrations instead of methods like add_column or create_table.
The con I see in doing this is that your project is less portable, you're tied to whatever database you're using. Not too big a deal I suppose since most databases use the same syntax to create tables, add columns, etc. So then my next though is, if that's the case then why do it? It seems less error prone to write ' add_column :addresses, :first_name, :string' than the SQL to do the same thing. It's also a lot more readable than the SQL statement is. The one thing I don't see migrations doing are foreign_key constraints in the database. I suppose a lot of Rails developers depend on the ActiveRecord associations and validations to enforce these? I'm interested in finding out what other folks are doing in terms of writing migrations. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
