不良数据库架构设计的升级策略

Question

我出现在一份新工作中并发现了急需一些帮助的数据库。它有很多问题，包括

• 没有外键......任何地方。他们是伪造的，使用int并在代码中管理关系。
• 实际上每个字段都可以NULL，这不是真的
• 表和列的命名约定实际上不存在
• Varchar s存储关联信息的串联字符串

人们可以争辩说，“它有效”，它就是这样。但是向前迈进，使用代码来管理所有这些操作是一件非常痛苦的事情，并让我们了解IMO的错误。基本上，DB被用作平面文件，因为它没有做很多工作。

我想解决这个问题。我现在看到的问题是：

1. 我们有很多数据（迁移，可能很棘手）
2. 所有数据库逻辑都在代码中（迁移带来了大量的代码更改）

我也很想做一些“激进”的事情，比如转移到无架构的数据库。

当面对基于设计不良的架构的现有数据库时，有哪些好的策略？

Answer 1

强制执行外键：如果域中存在关系，则它应具有外键。

重命名现有表/列充满了危险，特别是如果有许多系统直接访问数据库。陷阱包括仅定期运行的任务;这些经常被遗漏。

感兴趣：Scott Ambler的文章：Introduction To Database Refactoring

和Catalog of Database Refactorings

Answer 2

由于封装，视图通常用于在更改数据模型之间进行转换。视图看起来像一个表，但不作为数据库中的有限对象存在 - 您可以根据需要更改为给定列别名返回的列。这允许您设置代码库以使用视图，因此您可以从旧表结构移动到新表结构，而无需更新应用程序。但这意味着视图必须以现有格式返回数据。例如 - 您当前的数据模型具有：

SELECT t.column --a list of concatenated strings, assuming comma separated
  FROM TABLE t

...所以视图的第一个版本是上面的查询，但是一旦你创建了使用3NF的新表，视图的查询就会使用：

SELECT GROUP_CONCAT(t.column SEPARATOR ',')
  FROM NEW_TABLE t

......并且应用程序代码永远不会知道有任何改变。

MySQL的问题是视图支持是有限的 - 你不能在其中使用变量，也不能有子查询。

您希望进行的更改的实际情况是从头开始有效地重写应用程序。将逻辑从代码库移动到数据模型将彻底改变应用程序获取数据的方式。模型 - 视图 - 控制器（MVC）是实现这些变化的理想选择，可以最大限度地降低未来变更的成本。

Answer 3

我会说，在你真正了解之前不要管它。然后确保不要从Things You Should Never Do之一开始。

Answer 4

1. 创建一个全新的模式，并确保它完全规范化，并包含所需的任何唯一，检查和非空约束等，并使用适当的数据类型。
2. 使用单个“未知”记录预填充在外键关系中填充父角色的每个表。
3. 创建一个ETL（提取转换加载）过程（我可以推荐SSIS（SQL Server Integration Services），但是还有很多其他的）可以用来从现有的模式中重新填充新模式基础。使用“未知”记录作为任何孤立记录的父级 - 将有很多;）。您需要考虑如何合并重复记录 - 这可能需要根据具体情况而定。
4. 使用尽可能多的迭代来优化新模式（确保维护并定期运行ETL过程）。
5. 尽可能创建与现有架构匹配的新架构的视图。
6. 逐步修改任何客户端以使用新架构，在必要时临时使用视图。您应该能够逐渐关闭部分ETL过程并最终完全禁用它。

Answer 5

阅读Scott Ambler关于Refactoring Databases的书。它涵盖了许多关于如何改进数据库的技术 - 包括允许新旧程序使用不断变化的设计所需的过渡措施。

Answer 6

首先看看代码与数据库的关系有多糟糕如果在没有DAO层的情况下它们都是混合的，你不应该考虑重写，但是如果有DAO层那么就是时候重写那个层和DB了用它。如果可能，请根据使用两个DAO创建迁移工具。

但是我的猜测是没有DAO所以你需要找到你将要改变的代码区域以及与之相关的DB的哪些部分，希望你可以把它切成更小的部分，可以更新为你保持。最大的交易是在那里获得FK并开始检查正确的索引，很有可能他们没有正确完成。

在db的其余部分受到控制之前，我不会过于担心命名。对于NULL，如果程序阻塞值为NULL，则不要让它为NULL，但如果程序可以处理它，我将不会担心它在将来的这一点，如果它正在执行默认值移动到数据库，但这是事情的声音。

尽快做一些关于变形金刚的事情。如果有什么东西使第一个纯背景修复程序。

另一件事是估计每个区域的工作量变化，然后将该价格加到该部分代码的新开发成本上。这样，您可以在添加新功能时修复部件。