And in summary, the best practice I reckon is: Use seed at initial stage. Use migration after initial stage.
Tian On Sep 23, 11:05 am, Tianwen Chen <[email protected]> wrote: > 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.
