This question is motivated by a recent update to some business software a friend of mine is using. Their architecture was based on Access databases until now, which was awfully slow. They had split their datasets into multiple mdb files (sales.mdb, products.mdb, stock.mdb, …). They are now moving on to SQL Server Express and keeping this structure. Instead of using a table for each of these datasets, they created different databases on the same instance of SQL Server 2008 Express.
From my (admittedly limited) understanding of SQL Server, this does not seem sensible, as it prevents JOINs between different tables and requires a program that needs sales and stock data to maintain two DB connections instead of just one.
One of the software vendor’s consultants claimed that this would circumvent SQL Express’ RAM limit of 1GB physical memory – he says that is per-database, but from what I gather from MSDN, it’s actually per-instance, so they win nothing here.
Is there a good reason for splitting data in the same business domain into databases rather than tables?
(One that I can think of is that you can restrict access per database, but not per table – but this is irrelevant in this particular case, all modules of the program can access all databases.)
You can write joins across databases, so that’s not a major issue. Generally, I would suggest keeping everything in one database unless there was a very good reason to split it, and those reasons might have something to do with compatibility, say where you had an application that had to run against a database in compatibility mode 80 or something – you might choose to separate some data into a separate database at that compatibility level. Or if you had a major chunk of functionality that you wanted to be able to easily move to another server – say data migration, or ETL.
It sounds like the limitation is in the application.