How to store & deploy chunks of relational data?

I have a Postgres DB containing some configuration data spread over several tables. This configurations need to be tested before they get deployed to the production system. Now I'm looking for a way to

1. store single configuration objects with their child entities in SVN, and
2. to deploy this objects with child entities to different target DB's

The point is that the relations between the objects needs to be somehow maintained 开发者_如何学运维without the actual id's which would cause conflicts when copying the data to another DB.

For example, if the database would contain data about music artists, albums and tracks with a simple tree table schema like artist -> has albums -> has tracks, then the solution I'm looking for would allow to export e.g. one selected album with all tracks (or one artist with all albums with all tracks) into one file which could be stored to SVN and later be 'deployed' to whatever DB which has the same schema.

I was thinking of implementing something myself, e.g. to have config file describing dependencies, and an export script which replaces id's with PHP variables and generates some kind of PHP-SQL INSERT or UPDATE script. But then I thought it would be really silly not to ask before to double check if something like this already exists :o)

This is one of the arguments for Natural Keys. An album has an artist and is made up of tracks. No "id" necessary to link these pieces of information together, just use the names. Perl-esque example of a data file:

"Bob Artist" => {
    "First Album" => ["My Best Song", "A Slow Song",],
    "Comeback Album" => ["One-Hit Wonder", "ORM Blues",],
}, "Noname Singer" => {
    "Parse This Record!" => ["Song Named 'D'",],
}

To add the data, just walk the tree creating INSERT statements based on each level of parent data and if you must have one, use "RETURNING id" (PostgreSQL extension) at the end of each INSERT statement to get the auto-generated ids to pass to the next level down in the tree.

I second Matthew's suggestion. As a refinement of that concept, you may want to create "derived natural keys", for example "bob_artist" for "Bob Artist". The derived natural key would be well suited as a filename when storing the record into svn, for example.

The derived natural key should be generated such that any two different natural keys result in different derived natural keys. That way conflicts can't happen between independent datasets.

The concept of Rails migrations seems relevant although it aims mainly on performing schema updates: http://guides.rubyonrails.org/migrations.html

The idea has been transferred into PHP with the name Ruckusing, but seem to support only mySQL at this point: http://code.google.com/p/ruckusing/wiki/BigPictureOverview

Doctrine also provides migrations functionality but seems again to focus on schema transformations rather than on migrating or deploying data: http://www.doctrine-project.org/projects/migrations/2.0/docs/en

Possibly Ruckusing or Doctrine could be used (abused?) or if needed modified / extended to do the job?