views:

51

answers:

3

I have a general Database Design question: When is it better to create a new Database instead of adding new Tables to an existing? The question is related to design/maintainability andalso performance issues.

Background: we are mirroring the main tables of our customer by importing the data every night into our DB called RM2. Some new (ASP.Net-)Projects need access to this data too, now i'm wondering if i should create new databases for each project or merge their tables with the RM2(current size: 37991.94 MB).

A: 

You can get other database for projects if any project want use only self database. But if you want get datacenter of this you should create for it a other shared database + self database for each project.

Svisstack
+2  A: 

I won't necessarily answer your question, but I'll give you a bunch of other questions to consider as well:

  1. When should I add files to a filegroup in my database? - When files get too big, where "too big" may be a matter of opinion.
  2. When should I add a new filegroup to my database? - When you want to be able to optimize disk usage for different database operations.
  3. When should I add a new schema to my database? - When you have a set of objects that are logically related and may require different default permissions for users.
  4. When should I add a new database to my application? - When you don't need any referential integrity between any of the tables in the two databases. When you don't want to allow any ownership-chained permissions to cross between two sets of objects. When you want to independently backup and restore. When you want different SQL Server recovery models for two sets of data.

I guess that may have answered your question some. ;-)

John Bledsoe
So far i was "only" a developer in my previous jobs. Hence we created a database for every project and they were never related to each other. But now i have to maintain an existing huge database. Because every new project is somehow related to our RM2-Data i have already added new tables to it, but was wondering if this is the right way(logically/maintainability/performace). I have to consider creating point 1,2 and 3. I was not aware of the fact that cross db-referential integrity is not supported. Thanks for adding these questions.
Tim Schmelter
+1  A: 

This isn't a database design question. This is an organisational question. The organisational aspects of this question are much more important than technical questions.

The answer is: whatever makes life easiest for you as developers

For instance, you say:

Some new (ASP.Net-)Projects need access to this data too.

How integrated are these projects with your project? Do you actually share data (or write to the same tables)? For instance, if you make a breaking change to one of your tables, do you need to make changes to the code in the other projects at the same time? (Sometimes really hard to synchronize between two projects).

If you don't actually share data (apart from the customer data, which I assume is effectively read-only), then use separate databases (OR schemas). This makes changes a lot easier to manage.

Another trick is to have in each database a set of views onto the customer data, which lives in elsewhere, in another schema.

So, have a database per project, with views in each database onto the customer data, which lives in a single separate database.

Performance shouldn't really be an issue, unless the databases live on separate machines.

MatthieuF