Mark Parker wrote:
> We do exactly that; everything goes in it's own folder (Functions/,
> Tables/, Procedures/, etc.), and I developed a tool that puts them all
> together (resolving interdependencies) into a single script that can
> be used to "build" the database.
>
> To do an "upgrade" of an existing database, we do a "build" of the new
> version, then use a db-sync tool (red-gate SQLCompare, if you're
> wondering, but there's others out there) to make the existing database
> look just like the new database.
So you only keep create scripts?
What if you do a column update on a table? It's not like you can rerun a
create table on production. You only need to run a table update.
>
> We follow this model on many different databases, including some that
> have 300+ objects in them. It works very well for us.
>
> Mark
>
> Anastasios Angelidis wrote:
>
>> Next topic in order :D
>>
>> I'm thinking of scripting every element of a db: tables, stored
>> procs, functions, views for a particular project/component in their
>> own individual .sql files. To much maintenance?
>>
>> How do you guys go about this? c/c++, java etc... applications are to
>> easy to version! How about the database?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 4 16:40:38 2005