Hi,
We are discussing possible implementation for sql2005 database(s). This database will serve one web portal. Part of data will get into it by hand, and part will be replicated from internal system.
Some of us are for creating two separate databases, since there are two separate datasources. One, automatic, will change very little over time and requires almost no maintenance. Other datasource will be manual input. Tables and procedures related to this part will change over time.
Some of us are for creating single database, since it will serve one web site. More important this group is concerned about performance issues since almost every select will require join between tables that would be stored in two separate databases. Do these issues exist?
Can you share some insights, comments, links about this?
Hi,
We are using multiple databases in our many application, and have not found an excuse so far that we should terminate that practice. Most of our modules gather data from different databases and operate on them. I think a little performance overhead is there, which can be ignored.
As every approach has its pros and cons. But we think that this segregation provides us opportunity to
- encapsulate different type of data in separate locations,
- which can be backed up easily,
- can be distributed at different locations,
- due to lesser size data would be fetched rather fast,
- unorganized data could be separaterd.
Whats your take on it?
|||
We too use multiple databases (on the same server, of course) and join across them -- there is no performance penalty that we've ever seen.
In our situation, we have a vendor package around which we've written an extended application. The vendor package uses one database and our extension uses another, but the two are intimately linked and we have views in the extention database pointing back to the vendor packages database (making it very easy to code. I recommend that you too use views to make it appear as though it's one big database.
