我对数据库重构感兴趣。我处理了几个没有大量数据的数据库，只有几 GB，最多有几十万行。然而，它们有数百个——有时是数百个——表、视图、存储过程和函数。在某些地方，已经实施了使用模式的分而治之策略，这有助于解决查看表的所有权/使用情况的一些问题。然而，它并没有真正帮助对象耦合。
我们都读到通过共享数据库进行集成并不是一件好事，但我们也知道，至少在一段时间内，这是一件非常有成效的事情，因为一切都在数据库中。我们只是不像对对象那样将单一职责原则应用于数据库。
编辑：我应该补充一点，我没有数据库性能问题。表并不大，最大的只有几十万行。没有真正的数据库性能问题；除非数据库模式/逻辑/实现效率非常低下（比如需要游标对结果集中的每一行执行存储过程，以便为报告预处理数据）。在您说我应该更改这些之前，重点是：我不能，因为数据库不再处于可以评估更改影响的状态。
很明显，您有时会说“够了！” 并划分为通过消息、ETL、应用层等连接的多个数据库
问题是：多少才算太多？在你发疯之前，你可以拥有的 sprocs/tables/functions 数量的绝对上限是多少？
首先，不要再试图用面向对象的术语来考虑数据库。面向对象编程的原则根本不适用于关系数据库。
从业务角度来看，共享数据库是一件非常好的事情。存储必须在它们之间快速传输的信息的多个数据库变得比您的数百个对象要复杂得多。在企业应用程序之间保持一致的数据是无价的。如果 GE Corp 和 General Electric Corporation 真的是两个数据库之间的同一实体，那么试图调和可能是一场噩梦。
重构数据库是一个不错的目标，但实际上它非常复杂。除非您有需要解决的主要性能问题，或者除非您愿意致力于识别所有可能受更改影响的代码的过程，否则不要这样做。即便如此，考虑一下您是否知道所有可能更改的代码（这是数据库人讨厌、讨厌、讨厌动态代码的原因之一！）。
通常，重构的最佳方式是添加更改并开始转换为使用新字段、sp 等，同时将旧字段保留在原位，直到设定的到期日期。由于您处于年度周期，因此您需要在很长一段时间内管理这些日期。要查看是否正在使用 sps，您可以识别您不确定的那些，并向它们添加一些代码，以便在每次运行时插入到表中。如果在您的整个年度周期之后，它们还没有运行，您可以安全地消除它们。周期可能会更短，具体取决于 sp。
如果我正在编写仅每年运行一次的内容，我通常会在 sp 名称中添加“年度”一词。但这在您所在的位置可能并非如此，但是 sp 的功能应该让您了解它是否应该只定期运行。我不希望 usp_send email proc 每年只运行一次，但我可能希望 usp_attendance_report 可能不会经常运行。当然，正如我所说，我会将其命名为更像 usp_annual_attendance_report 的名称，您可以考虑继续做这种事情。
但是请注意，您所做的任何重构都必须在很长的周期内进行，以确保您不会删除您需要的内容。如果您的代码在源代码控制系统中（并且所有数据库表、sp、视图、UDF、触发器等都应该是），您可能可以消除一些事情，如果它们失败了，您可以立即将它们放回原处。再次，我会检查对象以确定消除它们可能存在的风险。
当然，如果您有良好的自动化测试，消除开发中的某些内容并运行测试可以帮助您确定是否仍在引用某些内容。
如果您正在寻找一种简单的重构方法，我不知道有哪一种。重构数据库是一项耗时、有风险的活动，并且对于愿意为此付费的权力而言，它可能没有显示出足够的改进。
一本关于重构数据库的好书是：http ://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321293533
我不确定你提到的任何事情都有一个神奇的限制。我更喜欢把东西放在一个地方，这样我就不必记住一些记录在适当的位置，而另一些记录在另一个地方。
我更想知道所有这些工作是否会影响您的表现？如果不是那么为什么要改变它？除非它以某种可怕的方式影响性能，否则您的客户不会从您的工作中看到任何好处，那么重点是什么？
如果您刚刚购买了新机器或升级了数据库服务器软件，您的客户可能会得到更好的服务。