这个问题的动机是我的一个朋友正在使用的一些商业软件的最新更新。到目前为止，他们的体系结构是基于Access数据库的，速度非常慢。他们已经将数据集拆分为多个mdb文件(sales.mdb、products.mdb，stock.mdb，…)。他们现在正转向SQL Server Express并保留这种结构。他们没有为每个数据集使用一个表，而是在SQL Server 2008 Express的同一实例上创建了不同的数据库。
从我对SQL Server的理解(诚然是有限的)来看，这似乎并不明智，因为它阻止了不同表之间的JOIN，并且需要一个需要销售和库存数据的程序来维护两个DB连接，而不是一个。
软件供应商的一位顾问声称，这将绕过SQL Express 1GB物理内存的RAM限制——他说这是每个数据库的内存，但根据我从MSDN收集到的信息，实际上是每个实例的内存，所以他们在这里一无所获。
是否有充分的理由将同一业务域中的数据拆分为数据库而不是表？(我能想到的是，你可以限制每个数据库的访问，但不能限制每个表的访问——但在这种特殊情况下，这是无关紧要的，程序的所有模块都可以访问所有数据库。)
您可以跨数据库编写联接，所以这不是一个主要问题。一般来说，我建议将所有数据都保存在一个数据库中，除非有很好的理由将其拆分，而这些原因可能与兼容性有关，比如说，您的应用程序必须在兼容性模式80或其他模式下针对数据库运行，您可能会选择在该兼容性级别将一些数据拆分到一个单独的数据库中。或者，如果您有一个主要的功能块，您希望能够轻松地转移到另一台服务器，比如数据迁移或ETL。
听起来限制在应用程序中。
根据您的SQL Server Express版本，拆分数据库可以允许更多的数据存储(2005年有4GB的数据库限制，2008年为10GB)。
除了每个实例1GB RAM的限制之外，我相信SQL Server Express还限制为每个实例1个CPU。
我同意哈博的评论。不能在数据库之间强制实施引用完整性，所有这些都必须在应用程序中进行管理。