Re: Database config managment

What about managing the script files themselves, keeping in mind that some
scripts could be applied to more than one database version, like a database
which is a branched version of another database, but which have common
elements which can both be updated by a common script. Although sometimes a
script would be unique to that database.

You're right about the tracking table. I used to use such a system at my
last place of work which we used to store the date it was applied, the
version, the developer and the description of the change. The added bonus
of that is since I work for a web development company which has a company
gateway, I could add version tracking information to that to show what has
been released into each environment. Hmmm... I feel some ideas forming.

Thom

2008/12/11 Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>

> On Thu, Dec 11, 2008 at 5:30 AM, Thom Brown <thombrown(at)gmail(dot)com> wrote:
> > What do you folk think is the best way to manage deployments to
> databases?
> > This would include things like table/view/function creations/changes and
> > possibly static data changes.
>
> The easiest way I've found to do it is to create a changetrack table
> in pgsql, and then make each update use that. You can get fancy if
> you want, or just keep it simple. For instance:
>
> create table chtrack (id int primary key, changename text, changedesc
> text);
>
> Then in a file you can have:
>
> begin;
> insert into chtrack (id, changename, changedesc) Values (10,'schema
> create','This change creates the initial db schema');
> create table
> etc...
> commit;
>
> If any of the script fails, the whole thing does and your db doesn't
> change. Then you can create your new updates in a similar manner.
>