For most database-backed projects I’ve worked on, there is a need to get “startup” or test data into the database before deploying the project. Examples of startup data: a table that lists all the countries in the world or a table that lists a bunch of colors that will be used to populate a color palette.
I’ve been using a system where I store all my startup data in an Excel spreadsheet (with one table per worksheet), then I have a utility script in SQL that (1) creates the database, (2) creates the schemas, (3) creates the tables (including primary and foreign keys), (4) connects to the spreadsheet as a linked server, and (5) inserts all the data into the tables.
I mostly like this system. I find it very easy to lay out columns in Excel, verify foreign key relationships using simple lookup functions, perform concatenation operations, copy in data from web tables or other spreadsheets, etc. One major disadvantage of this system is the need to sync up the columns in my worksheets any time I change a table definition.
I’ve been going through some tutorials to learn new .NET technologies or design patterns, and I’ve noticed that these typically involve using Visual Studio to create the database and add tables (rather than scripts), and the data is typically entered using the built-in designer. This has me wondering if maybe the way I’m doing it is not the most efficient or maintainable.
Questions
-
In general, do you find it preferable to build your whole database via scripts or a GUI designer, such as SSMSE or Visual Studio?
-
What method do you recommend for populating your database with startup or test data and why?
Clarification
Judging by the answers so far, I think I should clarify something. Assume that I have a significant amount of data (hundreds or thousands of rows) that needs to find its way into the database. This data could be sourced from various places, such as text files, spreadsheets, web tables, etc. I’ve received several suggestions to script this process using INSERT statements, but is this really viable when you’re talking about a lot of data?
Which leads me to…
New questions
-
How would you write a SQL script to take the country data on this page and insert it into the database?
With Excel, I could just copy/paste the table into a worksheet and run my utility script, and I’d basically be done.
-
What if you later realized you needed a new column, CapitalCity?
With Excel, I could take that information from this page, paste it into Excel, and with a quick text-to-column manipulation, I’d have the data in the format I need.
I honestly didn’t write this question to defend Excel as the best way or even a good way to get data into a database, but the answers so far don’t seem to be addressing my main concern–how to get all this data into your database. Writing a script with hundreds of INSERT statements by hand would be extremely time consuming and error prone. Somehow, this script needs to be machine generated, but how?
I think your current process is fine for seeding the database with initial data. It’s simple, easy to maintain, and works for you. If you’ve got a good database design with adequate constraints then it doesn’t really matter how you seed the initial data. You could use an intermediate tool to generate scripts but why bother?
SSIS has a steep learning curve, doesn’t work well with source control (impossible to tell what changed between versions), and is very finicky about type conversions from Excel. There’s also an issue with how many rows it reads ahead to determine the data type — you’re in deep trouble if your first x rows contain numbers stored as text.