是否有充分的理由将相关数据集拆分为不同的SQL数据库而不仅仅是表格?

时间:2012-12-18 01:19:25

标签: sql sql-server sql-server-express

这个问题是由我最近使用的一些商业软件的更新推动的。他们的架构基于Access数据库,直到现在,这非常缓慢。他们将数据集拆分为多个mdb文件(sales.mdb,products.mdb,stock.mdb,...)。他们现在正在转向SQL Server Express并保持这种结构。他们没有为每个数据集使用表,而是在同一个SQL Server 2008 Express实例上创建了不同的数据库。

从我对SQL Server的理解(通常是有限的),这似乎不合理,因为它阻止了不同表之间的JOIN,并且需要一个需要销售和库存数据的程序来维护两个数据库连接而不是一个。

其中一位软件供应商的顾问声称这会绕过SQL Express对1GB物理内存的RAM限制 - 他说这是每个数据库,但从我从MSDN收集的内容来看,它实际上是每个实例,所以他们什么都不赢这里。

是否有充分的理由将同一业务域中的数据拆分为数据库而不是表? (我能想到的一点是,您可以限制每个数据库的访问权限,但不能限制每个表的访问权限 - 但在这种特殊情况下这是无关紧要的,程序的所有模块都可以访问所有数据库。)

2 个答案:

答案 0 :(得分:2)

您可以跨数据库编写联接,因此这不是主要问题。一般来说,我建议将所有内容保存在一个数据库中,除非有一个很好的理由将其拆分,这些原因可能与兼容性有关,比如你有一个应用程序必须以兼容模式80对数据库运行或者某些东西 - 您可以选择将某些数据分离到该兼容级别的单独数据库中。或者,如果您有大量功能,您希望能够轻松地移动到另一台服务器 - 比如数据迁移或ETL。

听起来这个限制在应用程序中。

答案 1 :(得分:1)

根据您的SQL Server Express版本,将数据库拆分可能允许更多数据存储(2005年有4GB数据库限制,2008年为10GB)。

每个实例限制增加1GB RAM,我相信SQL Server Express每个实例也限制为1个CPU。

我同意HABO的评论。您无法在数据库之间强制实施参照完整性,这些都必须在应用程序中进行管理。