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 this
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, MCAD
Joining across databases is no problem (across instances can be, performancewise). 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 the 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 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 this
> 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, MCAD
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment