Re: Managing SQL in the repository

On 5/29/04 10:47 PM, "m christensen" <dfs@xmission.com> wrote:

> First Off I'll ASSUME y'all are not falling for the Micro$oft pitfall of
> bastardizing an
> official 30 year old standard definition, i.e."SQL" into a closed source
> proprietary brand name for
> Microsoft SQL Server.

Good lord, man. What do you think I am? Of course I know the difference.
Does anybody on this list really not?

> The approach taken will depend on the target of your development effort.
> The 2 general targets I see are
> a shipped product and incremental in-house system modification.

We are an incremental, in-house project so I'll respond to that portion of
your email.

> A. Actual backup copies of the Production database are restored as a
> starting point for databased used in part D.
> B. No Diff.
> C. All SQL EVER run against The Production database are checked in as
> patches. Both DDL & DML are included.

So to rebuild the database schema in this scenario, you'd have to run the
initial "create" script and then run the series of alter scripts that
brought everything "current"? Is that right?

> In other words, I don't care if it's 'Just a data change' or major
> table schema change.
> It's a script, it's checked in, and it has been tested or it
> doesn't run in production, Period.

I'm confused by this. You say above that you script (and revision-control)
all changes to the db including those for data. But then you say:

> It's hard enough to track system schema changes as shown here and in
> previous posts, but it is nearly IMPOSSIBLE to
> track production database data changes from a live system, after all the
> application is constantly changing data by definition.

Can you clarify?

> D. ALL Modern Decent Production level RDBMS Systems have a "Point in
> Time" recovery capability. IMHO.

We are, of course, doing incremental backups. My desire for a DDL "script
history" isn't just for their recovery value.

A DDL script history also lets us:

1) Easily setup duplicate test/development systems or build from scratch if
we need/want to.

2) They provide clear and detailed documentation on the evolution of the
database schema

3) They let us correlate this evolution to issues in our issue tracker.

4) They give us a good starting point for building scripts that implement
the database schema on other servers (something we're likely to be faced
with this summer).

> It's hard enough to track system schema changes as shown here and in
> previous posts, but it is nearly IMPOSSIBLE to
> track production database data changes from a live system, after all the
> application is constantly changing data by definition.
> I think the only real approach is to track overt system changes from the
> developers for other purposes but to admit the
> only way to get a copy of a database at a specific point is thru system
> backups and point-in-time recovery capabilities
> of the RDBMS itself.

Thanks for your detailed reply.

I don't think all the aspects of your system apply to us (we are not keeping
configuration data in the DB) but it's helpful to see that I'm not missing
"easy" solution. Misery loves company, I guess.

- Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 30 09:32:55 2004