Re: Version control for databases

On Mon, 15 May 2006, Baz wrote:

> We do let people go back and edit upgrade scripts. Mistakes can be
> made, and sometimes this would be necessary anyway, if a script would
> lose data.
>
> [...] Having a flexible naming scheme for the patch
> scripts is necessary or you'll end up with 3 people thinking they're
> creating script07.sql at some point...

I've done similar things in the past. It really comes down
to your developers. Currently, a strict naming convention
results in far fewer errors than arbitrary naming and forgetting
to update the index. The rule here is if you commit 07.sql
and get a conflict, that just means you update your sql
directory and rename your patch.

> Every time I see this stuff though, I wonder why version control of
> databases is *so* *hard*. Don't the DB vendors use version control
> themselves?

The great thing about DBs is that the logic is so close to
the data. The awful thing aboug DBs is that the logic is
so close to the data.

Plus, the vendors want to sell you versioning tools. That
use the DB as the backing store, of course...

-j

-- 
Jamie Lawrence                                        jal@jal.org
I learned to play guitar just to get the girls, and anyone 
who says they didn't is just lyin'! 
  - Willie Nelson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org