Data to pre-populate a database kept in text files

Question

Many web application require a seed file -- a file, written in the same language as a web application, where I have data to pre-populate a database. This makes sense.

Nonetheless, I sometimes see that some parts of that data is extracted into separate, text files to be read from the main seed.{rb, py, php} file and inserted into a database.

It can be a list of countries with languages and locales. Or a list of products for an internet-shop with descriptions, prices, etc. Or a list of articles for a blog. Whatever.

I wonder, why are kept in separate, text files which then read from the main seed.{rb, py, php} file and inserted into a database instead of keeping that in a seed file itself? What are the benefits of this approach? And when is this approach necessary?

Answer 1

There are virtually dozens of reasons why separating text files from the program which reads and processes them can be beneficial, even if the program is written in a scripting language (so in a text file itself) and both are always deployed together. By separating the text file, you can

• hand it over to another person who has no knowledge of the scripting language or programming at all and let the person create or maintain the file

• use a completely different editor (for example, a spreadsheet application), to maintain the text file

• give the data a version number different from the program

• let the same, untouched program process different variants of the text file (for example, for testing purposes, or for different, customized instances of the database)

• reuse the same script to populate different tables in your database easily from different text files, without the need to create a large, unmaintainable BLOB of a >10000 lines script

I guess if you think twice about the question, you can extend this list by a lot of further points by yourself.

Of course, if the task is just to fill one or two tables with two or three columns and rows, and the data virtually never changes, putting everything into one single script maybe sufficient and anything else unnecessary overhead. But if the task gets larger, separation of concerns becomes important.