2

我正在使用六个数据库。数据库都具有相同的架构、相同的 SP 等。对于最初设计数据库的人来说，使用许多数据库的很大一部分动机是效率；另一种方法是在数据库中的几乎每个表和 sp 中添加一列，指示正在处理哪组数据，从而产生一个巨大的（因此速度较慢的）数据库，而不是几个小型数据库。代替有一个列来指示正在查询的数据集，连接字符串用于选择正在访问的数据库。

我真正不喜欢这个组织的唯一原因是它涉及大量代码重复，因此会损害维护。例如，每次我希望更改存储过程时，我都需要在每个数据库上运行 alter 语句。

我考虑过的一种解决方案是将所有数据合并到一个大数据库中，并在整个位置添加一个额外的列，以指示如果我没有合并数据将在哪个数据库中。然后，我可以按此列的值对所有表进行分区。从理论上讲，所有这一切的结果是所有数据本身的基本表示在道德上将与现在相同，但没有索引、模式、SP 等方面的冗余。

我的问题是这样的：

  1. 这是一个好主意吗？有没有更好的方法来实现这一点？
  2. 这样做有什么问题吗？
  3. 这会对性能有什么影响吗？
4

3 回答 3

3

每个人都会在某个时候处理这​​个问题。我个人的看法是，多个数据库在背后很痛苦，而且速度并不快。由于维护头痛，它们很痛苦。如果索引设置正确，则根据需要在每个表中添加一个额外的列不会减慢您的处理速度。而且您的维护会容易得多。另外，跨多个数据库进行交易可能会很麻烦，并且涉及到 MTC。

顺便说一句，使用单个数据库通常称为多租户数据库。您可能想对此进行一些研究。但如果可能的话，我会避免使用多个这样的数据库。

于 2010-02-12T19:35:47.543 回答
1

我和兰迪的想法不同。

多租户模型有其优势。

一方面，无论您拥有 5 个数据库还是 500 个数据库，维护并没有太大的不同。在某些时候，您不再关注单个数据库的维护，而是查看集合。是的，您必须序列化备份，并且您不能一次在所有数据库中执行索引重组/重建。

但是对于跨多个或多或少相同的数据库的代码更改，有一些简单的方法可以编写许多要对多个数据库执行的操作，而无需真正增加额外的手指。我使用了一个名为 SQLFarms Combine 的工具（现在由 JNetDirect 出售），但我还没有使用过其他产品，例如 RedGate MultiScript。

我最喜欢多租户模型的一点是，当您增长和扩展并突然需要一个新的数据库服务器时，很容易将其中一个租户（例如，最繁忙或增长最快的）移动到新服务器。如果每个人都挤在同一个数据库中，那么仅提取他们的数据将变得非常困难，尤其是如果要最大限度地减少停机时间。在多租户模型中，您可以仅为他们的数据库设置镜像，然后在准备好时切换主数据库。

于 2010-02-12T19:43:53.287 回答
0

我赞成合并这些数据库。SQL Server 中内置了其他工具来解决非常大的数据库的潜在性能下降问题，例如在第二个物理磁盘上的附加索引、分区、集群等。将架构更新部署到这么多不同的数据库所涉及的头痛和开销在单个数据库中轻松处理时可能会很耗时。我认为 SQL Server 在这种情况下可以很好地扩展 - 让数据库服务器完成其设计的工作并提供对数据的响应式访问。您可以专注于应用程序设计并将存储模型留给 SQL Server。

另外，虽然上面没有提到这一点，但我怀疑在使用这种“多数据库”模型的应用程序中涉及到某种程度的动态 SQL，因为你必须根据你知道的东西在数据库之间切换，所以它不能硬编码到应用程序或配置文件中，这意味着必须即时生成连接字符串或实际的 SQL 语句，这可能是一个非常大的安全风险（如果你'不熟悉动态 SQL 的潜在风险）。

于 2010-02-12T19:51:52.680 回答