Database design suggestions

Question

0.00/5 (No votes)

See more:

Hi folks,

I'm developing a huge client application, which has a working DB taking care of the customer business at the moment.
It's an winforms C# client based application, that should take care of a lot of the business transactions going on in the business.
1. sub system were customer part (customer database)
2. sub system are going to be "business marketing".

So, the fiorst sub system are completed and done. Now I'm starting the analysing of 2. sub system, when I were marking some tho's.

Question:
Should I make both sub systems in ONE database (each got a span of about 20 tables with relations, and are undependant from each others (with one execption only, being postalcode table which both sub systems shares))?
Or should I make a database for each sub system?

+'s for several db's:
Will make the whole overview easier by time (expanding database over time by developing new features/sub systems)
-'s for several db's:
A few tables may be copied (like postalcodes) which can make redundancy and inconsistency.

+'s for ONE db with several sub systems:
There will not be any redundancy and inconsistency.
You don't have to make more than one connection to database in your application.
-'s for ONE db with several sub systems:
The database will be huge by time with developing.
The overview can be hard to keep over the database.

So, let me hear your's experiences and tho's, why?/why not?

Best Regards

Improved:
I'm using MSSQL lite version.
No matter what then the DB gonna be on the same virtual server, its just a question about one db schema or multiple.

Ain't there any "rules" for right and wrong database pattern for making databases for several sub-system? Or is it just a "I prefer" question?

Posted 6-Apr-10 5:03am

grmihel2

Updated 7-Apr-10 0:22am

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

leckey · Answer 1 · 2010-04-06T07:23:00

Do you anticipate one db being a lot larger than another? Will the tables in each sub-system interact with each other frequently? Are you using SQL Server for your databases?

I personally like separating out databases when possible. I hate having huge schemas that I have to dig my way through. Even if you have separate databases, you can reference a table in the other database (such as postal codes) so you don't have to upkeep two versions of the same table. You may want to separate them depending on security and user access also. By having multiple databases if you need to take one offline for something, you can leave the others up and not hold up everyone's work.

There's more detail to it than that, but I prefer multiple databases. Now wether you want to keep them on different servers, that's another debate.