info-cvs
[Top][All Lists]
Advanced

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

RE: CVS best practice


From: Rick Genter
Subject: RE: CVS best practice
Date: Thu, 22 Jul 2004 12:42:57 -0700

Thanks, Shane, that actually helps a lot. 

-----Original Message-----
From: Shane Turner [mailto:address@hidden 
Sent: Thursday, July 22, 2004 3:31 PM
To: Rick Genter
Cc: address@hidden
Subject: Re: CVS best practice

Rick Genter wrote:

>My question is more a question of best practice as opposed to how to 
>use CVS.
>
>The system I work on consists of a number components. Each component is

>a separately built Java application, all referencing portions of a 
>common database. Different components use different tables; some tables

>are shared by many components, while some are used by a single 
>component. Over the life of the system, schema changes on the same 
>table may have been required by different applications for different
purposes.
>
>We script all of our database changes and store the scripts in our 
>repository, but this has led to some "spirited" debate about repository

>structure. Our DBA wants to have a database-centric repository 
>hierarchy where all database scripts are stored in a CVS module named 
>for the database to which the script applies. There would be submodules

>for Tables, Stored Procedures, Indexes, etc. I, on the other hand, want

>scripts associated with a particular application to be stored in "SQL"
>or "Schema" submodule under the module for that application.
>
>What do others do?
>--
>Rick Genter
>Sr. Software Engineer
>Silverlink Communications
><mailto:address@hidden>
>(781) 272-3080 x242
>  
>
Here we treat the database as its own application with interfaces
defined by the stored procedures. The stored procedures let us change
the schema without necessarily changing the stored procedures used by
the applications. If the interface to the database needs to change for
an application, then that requires a release of the database before or
at the same time as the application release. We also aim to ensure that
when an application requires a new interface the existing interface
continues to exist until that new application is in place. This helps us
de-couple the database from the applications. Of course things don't
always work that cleanly, but that's usually due to a more radical than
usual shift in schema.

I hope that helps,

Shane

--
Shane Turner, Senior Software Engineer | InfoInterActive Corp. (An AOL
Company)
E address@hidden     | W www.infointeractive.com
AIM: iiaShane ICQ: 60761162            | V: 902-832-2633 F: 902-832-1015
-----BEGIN GEEK CODE BLOCK-----
GCS d-(+) s: a- C++$ ULS++ P+(++) L++ E@ W+ N o? K? w O M- V !PS !PE Y+
PGP
t++@ 5+ X+ R tv b+ DI+ D+ G e++ h--- r+++ y+++
-----END GEEK CODE BLOCK-----





reply via email to

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