数据库中有多少个表/ sprocs /函数太多？

Question

我对数据库重构感兴趣。我处理几个数据库，这些数据库没有大量数据，只有几GB，最多有几十万行。但是，它们有数百个 - 有时是数百个 - 表格，视图，sprocs和函数。在一些地方，使用模式的分治策略已经实施，这有助于看到所有权/使用表的一些问题。但是，它并没有真正帮助对象耦合。

我们都知道integration via shared database不是一件好事，但我们也知道它至少在一段时间内是一件非常有成效的事情，因为一切都在数据库中。我们不会像对待对象那样将Single Responsibility Principle应用于数据库。

编辑：我应该补充说我没有数据库性能问题。表格并不大，最大的只有几十万行。没有真正的数据库性能问题;除非数据库架构/逻辑/实现非常低效（例如，要求使用游标对结果集中的每一行执行sproc执行以预处理报表数据）。在你说我应该改变这些之前，这就是整个观点：我不能因为数据库不再处于可以评估变化影响的状态。

显然在某个时候你说“够了！”并分为多个数据库，通过消息，ETL，应用程序层等连接。

问题是：有多少是太多？你疯了之前可以拥有的sprocs/tables/functions的数量的绝对上限是多少？

Answer 1

我不确定你提到的任何事情都有一个神奇的限制。我更喜欢把东西放在一个地方，所以我不必记住有些记录已经存在，而其他记录就在另一个记录中。

我会更有兴趣知道这些工作是否会影响您的表现？如果不是那么为什么改变它？除非它以某种可怕的方式影响性能，否则您的客户将无法从您的工作中看到任何好处，那么有什么意义？

如果您刚买了新机器或升级了数据库服务器软件，您的客户可能会得到更好的服务。

Answer 2

首先，停止尝试以面向对象的术语思考数据库。面向对象编程的原则不适用于关系数据库。

从业务角度看，共享数据库是一件非常好的事情。存储必须在它们之间传输信息的多个数据库很快变得比您想要的数百个对象复杂得多。企业应用程序之间一致的数据是无价的。如果通用电气公司和通用电气公司是两个数据库之间真正相同的实体，试图调和可能是一场噩梦。

重构数据库是一个不错的目标，但实际上它非常复杂。除非您遇到需要解决的重大性能问题，否则不要这样做，除非您愿意承诺识别可能受到更改影响的所有代码的过程。即便如此，请考虑是否可以知道所有可能会更改的代码（这是数据库人员讨厌，讨厌，讨厌动态代码的原因之一！）。

通常，重构的最佳方式是添加更改并开始更改为使用新字段，sp等，同时保留旧字段直到设置到期日期。由于您处于年度周期，您需要长时间管理这些日期。要查看是否正在使用sps，可以识别不确定的sps，并在它们运行时向其中添加一些代码以插入到表中。如果在整个一年的循环之后，它们还没有运行，您可以安全地消除它们。取决于sp，周期可能更短。

如果我写的东西只能每年运行一次，我通常会在sp名称中加上“年度”一词。但是，在那里你可能并不是真的，但是，sp的功能应该让你知道它是否应该只是定期运行。我不希望usp_send电子邮件proc每年只运行一次，但我可能会认为usp_attendance_report可能不会经常运行。当然，正如我所说的，我会把它命名为更像usp_annual_attendance_report，你可以考虑继续前进。

但请注意，您所做的任何重构都必须在长周期内进行，以确保您不会删除所需的内容。如果您的代码位于源代码管理系统（以及所有数据库表，sp，视图，UDF，触发器等）中，那么您可能会排除一些知道如果它们失败的事情，您可以立即将它们放回原处。再次，我会研究这个对象来确定消除它们可能存在的风险。

当然，如果你有良好的自动化测试，在dev上删除一些东西并运行测试可以帮助你发现是否仍有某些东西被引用。

如果您正在寻找一种简单的重构方法，我不知道其中之一。重构数据库是一项耗时且危险的活动，对于愿意为其付费的权力，可能不会有足够的改进。

一本好书重构数据库是：http://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321293533