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