I have several SQL databases that I am going to create that will all share a
basic part number/part description table, as well as a common customer table
.
What is the best way to design this? Should I have a central database that
contains the master tables and then have all of the other tables link to thi
s
table?, or should I set each database with their own copy of this part
number/customer table so they can link to those instead (and then setup some
type of replication)?
I just was not sure if it was good practice to be constantly joining tables
from two different databases each time a SELECT statement is run.
Any help would be appreciated.
Thank you.
Scott Fox, MCADJoining across databases is no problem (across instances can be, performance
wise). You cannot define
foreign keys, though. So data integrity (RI) has to be done using triggers.
There's no best way,
though. Consider advantages and disadvantages for both approaches and use th
e one that suits you
best. And handle the disadvantages that the solution has.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Scott" <Scott@.discussions.microsoft.com> wrote in message
news:F9BC8DAB-6122-4BC8-AA45-90DCED9EEE79@.microsoft.com...
>I have several SQL databases that I am going to create that will all share
a
> basic part number/part description table, as well as a common customer tab
le.
> What is the best way to design this? Should I have a central database tha
t
> contains the master tables and then have all of the other tables link to t
his
> table?, or should I set each database with their own copy of this part
> number/customer table so they can link to those instead (and then setup so
me
> type of replication)?
> I just was not sure if it was good practice to be constantly joining table
s
> from two different databases each time a SELECT statement is run.
> Any help would be appreciated.
> Thank you.
> Scott Fox, MCAD
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment