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.
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
Received on Fri Nov 4 16:19:46 2005