sql-server - 数据库中有多少个表/过程/函数太多？

Question

我对数据库重构感兴趣。我处理的是几个没有大量数据的数据库，只有几个GB，最多几十万行。但是，它们具有数百个(有时甚至数百个)表， View ，存储过程和函数。在某些地方，已经实施了使用模式的分而治之的策略，这帮助解决了查看表所有权/使用率的一些问题。但是，它并没有真正帮助对象耦合。

我们都读过integration via shared database不是一件好事，但我们也知道，至少在一段时间内，它是非常有生产力的事情，因为所有内容都在数据库中。我们只是不像对对象一样将Single Responsibility Principle应用于数据库。

编辑:我应该补充一点，我没有数据库性能问题。表不是很大，最大的表只有几十万行。没有实际的数据库性能问题；除非数据库模式/逻辑/实现的效率极低(例如，要求游标对结果集中的每一行执行sproc执行以预处理报表数据)，否则除外。在你说我应该改变这些之前，这就是重点:我不能，因为数据库不再处于可以评估变更影响的状态。

显然，您有时会说“足够了!”并分为由消息，ETL，应用程序层等连接的多个数据库

问题是:多少太多？疯狂之前可以拥有的存储过程/表/函数的绝对上限是多少？

Answer 1

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

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

重构数据库是一个不错的目标，但实际上它非常复杂。除非您遇到需要解决的主要性能问题，或者除非您愿意执行确定所有可能受更改影响的代码的过程，否则请不要执行此操作。即使那样，请考虑是否您知道所有可能更改的代码(这是数据库人员讨厌，讨厌，讨厌动态代码的原因之一!)。

重构的最佳方法通常是添加更改并开始转换为使用新字段，sp等，同时将旧字段保留在原处，直到设置的到期日期。由于您处于年度周期，因此您需要长期管理这些日期。要查看是否正在使用sps，可以确定不确定的对象，并向其中添加一些代码以在每次运行时将其插入到表中。如果在您的整个年度周期之后仍未运行它们，则可以安全地消除它们。取决于sp，周期可能会更短。

如果我写的东西只能每年运行一次，通常我会在sp名称中加上“annual”一词。但是，无论您身在何处，这可能都不正确，但是sp的功能是否应该仅定期运行才可以使您有所了解。我不希望usp_send电子邮件处理仅每年运行一次，但我可能希望usp_attendance_report可能不会经常运行。当然，正如我所说的，我将其命名为usp_annual_attendance_report之类的东西，您可以考虑将其向前推进。

但是请注意，您所做的任何重构都必须花费很长时间才能确保您不会删除所需的内容。如果您的代码在源代码管理系统中(并且所有数据库表，sp， View ，UDF，触发器等都应该存在)，则可以消除某些事情，因为知道它们失败了，您可以立即将它们放回原处。再次，我将检查对象以确定消除它们的潜在风险。

当然，如果您有良好的自动化测试，那么在开发人员身上消除一些麻烦并运行测试可以帮助您了解是否仍在引用某些东西。

如果您正在寻找一种简单的重构方法，我不知道。重构数据库是一项耗时，高风险的 Activity ，对于愿意为之付费的功能而言，它可能无法显示出足够的改进。

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