: What to do with database in dev/production phases of a website? For a while now I've been keeping a website I'm developing in the standard dev/production phases. Its been pretty simple: Mercurial

@Barnes591

stackoverflow.com/questions/1607/mechanisms-for-tracking-db-schema-changes

Vote Up Vote Down

@Ogunnowo487

Most revision control systems are designed for source control. They're not designed for versioning other sorts of data, like binary data or databases.

In most cases, there isn't really a reason to version your data--not for development anyway. Generally, your source code ought not to rely on a particular data state.

Usually, what's versioned is the schema (and maybe stored procedures). And since the only way this can be meaningfully done is for the diff engine to contain a full DDL parser, the revision control system is usually tied to the data modeling software you're using.

But since that type of software can be quite expensive, there are also other options. For instance, you could simply version a schema dump or a database creation/initialization script. Alternatively, you could manually write upgrade scripts to upgrade from one version of the database to another. This can be a pain, but that's why you should try to get your data model correct from the start. If you're constantly changing your database schema from one revision to the next, then you're probably doing something wrong.

As for the data, I usually just store test data separately in a CSV file or something. And that can typically be imported automatically through the application, which will handle the conversion process to whatever database schema it's using.

Vote Up Vote Down

@Karen161

The solution actually may depend on database used.

But generally, keep three servers (dev, test, prod), and work separate structure dump from data dump. You can keep versioning track of structure through the generated SQL files.

Well, I've seems this process being used for many medium/big projects, and I recommend it.

Vote Up Vote Down