Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
M.Paul
Starting Member
2 Posts |
 Posted - 2005-12-31 : 17:08:57
|
| Hello,The company I work for is made up of 8 divisions, such as accounting, workers comp, sales, etc. Right now, each division has their own seperate application and database. We are now begining to talk about integrating these applications into one main application. Is it typical to have one database that houses each divisions tables or would you still keep a seperate database for each division? Right now, there is a Client database that stores all of our clients, so each database needs to read from this centralized database whenever we need client info, which is fine and dandy, but how do you handle situations like enforcing referential integrity across databases? I know each company is different on how they do these types of things, but how do you guys think the majority handles this (one main database or multiple smaller databases)?Thank You |
|
|
M.Paul
Starting Member
2 Posts |
Posted - 2006-01-02 : 12:21:12
|
| Bump.. |
 |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2006-01-02 : 17:29:08
|
only triggers can enforce RI over databases.i'd go with one single DB's and tables for each division.Go with the flow & have fun! Else fight the flow  |
|
|
|
afrika
Master Smack Fu Yak Hacker
2706 Posts |
Posted - 2006-01-03 : 03:54:53
|
One db.works best, esp when you have to get your fiscal/accounting years and reconciliation years.quote:
needs to read from this centralized database whenever we need client info
|
|
|
|
AndrewMurphy
Master Smack Fu Yak Hacker
2916 Posts |
Posted - 2006-01-03 : 07:43:48
|
| There's no 1 correct answer. You've to balance to conflicts of the benefits of 'data integrity/single data store' with the potential different needs of the divisions...ie manufacturing want 27x7 uptime, whereas accounting want multiple re-runs of EOY/EOD/EOM processes because 'the figures aren't right'. Also...single database = single point of failure = single commitment to an operational schedule. You'll have a list of pro's/con's to generate and evaluate. Good luck! |
|
|
|
afrika
Master Smack Fu Yak Hacker
2706 Posts |
Posted - 2006-01-03 : 10:34:11
|
| Well true, no 1 correct answser. But there are best practices. Am not defending one db. But if you are looking at 24/7 uptime then many other features come into play.... also note, if all the users are in one db, and they login via that db, when that db goes down and others are up and running, it would still affect it |
|
|
|
yonabout
Posting Yak Master
112 Posts |
Posted - 2006-01-03 : 10:38:59
|
| I prefer single databases, but sometimes they just aren't practical, especially where accounts are concerned. We're trying to integrate a number of systems so it appears seamless to the users - one of these is an accounts package, and this has had to be kept separate because it was deemed too risky to hold it in with other data. The biggest problem we're having isn't the referential integrity across the databases, but making sure that backups and restores are scynchronised across all the db's. We're using transactional logs at the moment, and we've only had to do it once, but it wasn't fun.Cheers,Yonabout |
|
|
|
|
|
|
|
|
Database Design Question. Pls Comment