Hi,
I work in ERP for a large company (that shall forever remain nameless),
and I think my experiences might benefit you a bit.
We use databases for our "stateful" data as you call it. I might call
it 'enterprise data' or 'business data'. When we do an upgrade to
database schemas usually its extending a table by adding a column, and
that can be done with a minimal outage (for live production systems)
and extending the database table. Without reloading the table (AFAIK,
I'm not a DBA). In any case, backups are your best friend when doing
any potentially destructive work on systems.
I think SVN has a role to play in management of the database "source" -
that is stored procedures (which suck) and schema specifications.
Management of the data itself is usually done with database backups,
save, restore, and all that good stuff.
I hope this helps.
Regards,
-ryan
On Sunday, June 22, 2003, at 09:58 PM, Daniel Patterson wrote:
> Greetings all,
>
> I'm looking for advice on the best practises for configuration
> management of stateful data.
>
> This situation comes up in a few different places, but the
> best example (and the one I have right now) are database
> schema changes between software releases.
>
> For stateless portions of the system (i.e. the application
> code), it's easy to overwrite, or drop/replace (in the case
> of database stored procedures). However, stateful portions
> (i.e. database tables with data in them, configuration files,
> any other stateful information that may undergo a schema change),
> the usual configuration management procedures don't apply.
> You can't drop 12 months of data from your database because
> you need to rename a relational table....
>
> A bit of searching around on google didn't reveal anything,
> but it's hard to know if I'm searching for the wrong thing or
> if nothing really exists.
>
> I've thought a bit about the process that Subversion takes
> (a dump into a known format followed by a reload), but in
> our situation, building a tool like that is impractical.
>
> Has anyone done any deep thinking about this topic and come
> up with any good patterns to follow?
>
> daniel
> --
> Signature at:
> http://www.mel.au.adaptiveinternational.com/~danpat/signature.txt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 07:09:06 2003