Managing SQL in the repository (was: Organization Advise)

On 5/28/04 2:42 PM, "Brad Rhoads" <brhoads@zethcon.com> wrote:

> How do we
> deal with the SQL as it is functionally related to other parts of the
> system?

We're dealing this this one, too, right now and our solution for Store
Procedures is this:

1) We require that our developers "script" their schema-related (not data
related) changes to the script. In short, they're not allowed to simply
open up an sproc-editor and make a quick change. They have to put the
change in a "create sproc" script.

We keep these scripts in a directory on our repository.

2) Ensure that the "script" is written such that it drops the old resource
before adding the new one. In short we disallow the use of alter statements
for sprocs.

3) We require that there is one file for every sproc on the database.

And then we just manage those scripts as if they were standard code.

This gets us all the normal repository abilities (snapshots, branches,
merges, diffs) on sproc-related SQL resources.

----
Tables are trickier because we can't "drop" the old table before adding new
one (the data would go away).  This means we're forced to use alter
statements to make table-related mods (instead of the drop/replace scheme we
use for sprocs).
And that means that a table's given state is a combination of the original
create-scripts and a handful of alter scripts that have come after its
original creation.  Which means no ability to easily diff different table
versions.
So for table-related DDL, I'm still not sure how we'll be handling it, I'd
love to hear some suggestions.
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org