Hi everyone, I just want to raise a discussion as titled and try to find out some best practices.
I personally choose migration over seed only when we need to make changes after the app is online. >From what I can see, the purpose of seed is when you have a completely new database, you can populate essential data for the app to use. The purpose of migration is when you need to make changes to the database schema, or data which people don't suggest to. Let's now think about the following scenarios: 1. Initial stage of the app Apparently, you should use seed in here instead of migration. 2. The app is already in production running, and you need to populate more data for some of the tables. For example, need to add more categories for products. Here, you can use either seed or migration. But for seed, you need to identify the existing record in the database in case you might create duplicate records. 3. The app is already in production running, and you need to remove some data in the database. For example, the client wants to remove the products and as well as their categories. Here, you will prefer migration over seed. As seed shouldn't be used to remove data from literal. Let's now take a look at their benefits and drawbacks: Benefits of using seed: 1. separate the obligation of data populating from migration at initial stage, place the thing where it should be Drawbacks of using seed: 1. no timestamp, you can't trace the history when changes were made 2. have to prevent inserting duplicate records when you want to insert new record 2. no rollback as you just can't 3. it is not included in the db:migrate rake task, therefore, you have to run the db:seed every time after the deployment until you automate this process in capistrano. PS: by using seed_fu or other gems, you may now take off the second drawback. Benefits of using migration: 1. timestamp is provided 2. you can rollback the changes as you want 3. you can either insert, update, and delete data Drawbacks of using migration: 1. should separate the data changes and database schema changes. (Here, I want to say, even if I put the data manipulation in db migrate, there is no harm of doing this. If you want to argue this is messy, how does db migration doesn't look messy to you, the reason we want to have db migration is we wish to trace when we did the changes and whether we can revert. This is what seed not capable for.) Welcome to discuss:) Kind Regards, Tian -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en.
