We have a requirement for a new feature which requires some seed data to be present in the database (basically some default values) for the feature to function correctly. We have this in 2 different scenarios at the moment, and the best method of generation / insertion of the seed data seems to vary depending on the data store we use. I'm not talking about seeding data for test purposes here.
For example, some features require tables to be present in SQL Server. We're using manual migrations between versions (basically diffing the schemas) so inserting the seed data for this would make sense to be done in the same SQL script that updates the schema. The way that some ORMs seem to handle this is to have a Seed() method (or equivalent) in the initialisation code which will create the data.
A different feature is using Azure Table Storage (ATS) as it's data store. Being schema-less, there's no script to create the table here, but the application does check for the existence of the tables on first run, and creates them if it doesn't exist there. This means that we normally don't create the tables before the deployment goes ahead. To seed data in ATS we could either pre-populate the environment (which would require some code to be written and executed somewhere) or we could make the component that checks for the existence of the table insert the data as it's created.
Is there a long term disadvantage to having the seed data in classes in the code, and if that's the best place to put it, is it going to make more sense to keep the data together (eg having a Seed class with the data in it that's run on app startup) or should the Repository have the responsibility for making sure that the base data exists before issuing any queries?