How to have a “master-structure” database with “children-data” databases in SQL SERVER 2005?

Question

I have been googling a lot and I couldn't find if this even exists or I'm asking for some magic =P

Ok, so here's the deal.

I need to have a way to create a "master-structured" database which will only contain the schemas, structures, tables, store procedures, udfs, etc, everything but real data in SQL SERVER 2005 (if this is available in 2008 let me know, I could try to convince my client to pay for it =P)

Then I want to have several "children" of that master db which implement those schemas, tables, etc but each one has different data.

So when I need to create a new stored procedure or something like that, I just create it on the master database (and of course it's available on its children).

Actually I have several different databases with the same schema and different data. But the problem is to maintain congruency between them. Everytime I create a script to create some SP or add some index or whatever, I have to execute it in every database, and sometimes I could miss one =P

So let's say you have a UNIVERSE (would be the master db) and the universe has SPACES (each one represented by a child db). So the application I'm working on needs to dynamically "clone" SPACES. To do that, we have to create a new database. Nowadays I'm creating a backup of the db being cloned, restoring it as a new one and truncate the tables. I want to be able to create a new "child" of the "master" db, which will maintain the schemas and everything, but will start with empty data.

Hope it's clear... My english is not perfect, sorry about that =P Thanks to all!

Answer 1

What you really need is to version-control your database schema.

See do-you-source-control-your-databases

If you use SQL Server, I would recommend dbGhost - not expensive and does a great job of:

• synchronizing 2 databases
• diff-ing 2 databases
• creating a database from a set of scripts (I would recommend this version).
• batch support, so that you can upgrade all your databases using a single batch

You can use this infrastructure for both:

• rolling development versions to test, integration and production systems
• rolling your 'updated' system to multiple production deployments (especially in a hosted environment)

Answer 2

I would write my changes as a sql file and use OSQL or SQLCMD via a batchfile to ensure that I repeatedly executed on all the databases without thinking about it.

As an alternative I would use the VisualStudio Database Pro tools or RedGate SQL compare tools to compare and propogate the changes.

Answer 3

There are kludges, but the mainstream way to handle this is still to use Source Code Control (with all its other attendant benefits.) And SQL Server is increasingly SCC friendly.

Also, for many (most robust) sites it's a per-server issue as much as a per-database issue.

Answer 4

You can put things in master like SPs and call them from anywhere. As far as other objects like tables, you can put them in model and new databases will get them when you create a new database .

However, in order to get new tables to simply pop up in the child databases after being added to the parent, nothing.

It would be possible to create something to look through the databases and script them from a template database, and there are also commercial tools which can help discover differences between databases. You could also have a DDL trigger in the "master" database which went out and did this when you created a new table.

If you kept a nice SPACES template, you could script it out (without data) and create the new database - so there would be no need to TRUNCATE. You can script it out from SQL or an external tool.

Answer 5

Little trivia here. The mssqlsystemresource database works as you describe: is defined once and 'appears' in every database as the special sys schema. Unfortunately the special 'magic' needed to get this working is not available to the user databases. You'll have to use deployment techniques to keep your schema in synk. That is, apply the changes to every database as the other answers already suggested.

Answer 6

In theory, you could put a trigger on your UNIVERSE.sysobjects table (assuming SQL Server), and then you could enumerate master.dbo.sysdatabases to find all the child databases. If you have a special table that indicates it's a child database, you can reference child.dbo.sysobjects to find it.

Make no mistake, it would be difficult to implement. But it's one way you could do it.