[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SQL shema

From: Philip Lijnzaad
Subject: Re: SQL shema
Date: 11 Oct 2001 13:54:04 +0100

> hi,
> I was wondering how u people are working with SQL-shema changes... say I
> have it under CVS control...
> How u automate adding/removing tables and fields,  and as special case
> populating some of the tables...!!

CVS is not a build tool. 

To make sure that all the schemata and the application code (all of it) is
consistent, you really have to have regression tests that exercise all of the
table definitions. Only when all regression tests pass would you commit *.sql
and application code to CVS (or rather, it would be commited earlier, but
given it some significant tag or branch when everything flies again).

This is not trivial, especially if people have to hand tweak the schema's
inside the databases (which is not uncommon). If they do so, dump the schema
from the database, can commit it.

I would suggest using a layer of view definitions (to be used by the
application code) can help insulate you from schema churn.

A final scenario is that the tables definitions are embedded in the
applications (e.g. if you have some object layer). In this case, *.sql is
a derivation, hence should not be stored under CVS.  

The mail transport agent is not liable for any coffee stains in this message
Philip Lijnzaad, address@hidden European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639                 Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           Cambridgeshire CB10 1SD,  GREAT BRITAIN

reply via email to

[Prev in Thread] Current Thread [Next in Thread]