如何在糟糕的数据库之上构建一个好的API？

Question

我有一个设计糟糕的数据库。由于各种原因，它需要保持这种状态。

根据我的经验，我喜欢像ActiveRecord这样的ORM，但是只有在没有现有数据库的情况下才将它们用于新项目。

有没有办法在不更改设计糟糕的数据库的情况下使用ActiveRecord样式的ORM建立良好的数据模型？

Answer 1

其他人已经触及了这方面的技术方面，所以我想添加另一个观点：

暂时停止聆听您的二元感受，并尝试专注于使用当前设计的现实后果。如果以此作为起点，您将遇到的问题究竟是什么？

• 这会让您的项目需要更长时间才能完成吗？
• 是否需要更多人？
• 是否需要特殊的能力才能与之合作？
• 是否会危及数据质量？
• 是否会使维护更难？
• 会对性能产生严重影响吗？
• 对你之后的下一个项目有什么影响？

和

• 为了从当前状态转移到所需状态需要做什么
• 这样做的成本是多少
• 如果您首先需要修改设计，对当前项目有什么影响？

因为最终，这种东西真的很重要。如果你不能“出售”这个设计很糟糕的想法，那真的不是，而你只是在讨论那些对我们这些同样生活在二元世界中的同伴们来说无关紧要的事情{{ 1}}。

当然这个bigint列可能已经被tinyint替换了，那些列应该已经被移动到另一个表中了，这段重复的逻辑可能隐藏在一些视图/函数后面，而且这个API会慢于neccesary ，但这些都是在非二进制世界中可能或不重要的糟糕细节。

我有一张最喜欢的桌子，讨厌工作。大约1％的数据不一致，而且完全错误。清理最后1％的成本将是巨大的（来自多个系统的合并数据），并且在聚合时甚至不会以小数形式显示错误。事实上，有一个问题是我。我无法向表中添加特定约束。所以我必须使用它为2个程序添加where谓词。我已经多次尝试过修复它，但是没有人愿意投资那些没有问题的东西。我同意他们的意见。

Answer 2

这样的问题有很多好的答案。有些比其他更好。理想情况下，我可以想到两个解决方案，它们都来自同一个想法。装饰器。

因此，如果数据库设计很差，那么提高代码质量的最佳方法是提出正确的域模型并在数据库顶部装饰一层以正确使用底层数据模型。

第一种方法是：

1_大多数ORM允许一种方法将多个表表示为单个实体，反之亦然。但这种解决方案很复杂，充满了危险。

2_我首选的解决方案是使用数据库反规范化技术，如视图，物化视图和过程，在数据模型之上创建一个新层，并在该层之上创建一个ORM。 （最好在所有者架构上创建一个新架构并创建view \ mv。这样，任何使用旧架构的应用程序都可以继续工作，并且您可以完全控制如何设计数据访问层。）。

Answer 3

我把你的问题重写为：

  

应用程序编程接口是否具有理想或积极的品质，特别是那些适用于具有不良或负面品质的数据库的东西？

所以我对你的数据库的答案是：

• 如果消极品质可以忽略不计，那么是。
• 如果是负面的 - 并且通过额外的工作可以忽略不良品质，那么可能是的。
• 如果出现不良表现或行为，则可能没有。
• 如果数据库有效，但仅在最佳情况下，那么没有。

Answer 4

考虑一下这一点。真。

我有一个潮湿问题的房子。由于各种原因，它需要保持这种状态。

根据我的经验，我喜欢装饰如抹灰和墙纸，但只在没有潮湿问题的房子里使用它们。

有没有办法用抹灰和墙纸等装饰来创造一个没有潮湿问题的房子，而不会改变房屋内的潮湿问题呢？

Answer 5

这取决于该数据库中的可怕之处。如果数据库具有错误的表和列名称，坏列数据类型或错误的访问层（如存储过程，视图等），您仍然可以使用您喜欢的ORM并将错误的数据库映射到漂亮的模型。但是，如果数据库与某些正常形式不匹配，则可能会导致映射到模型时出现问题。

Answer 6

我唯一能想到的是，你可以“重命名”数据库字段作为方便（如果不是这样的话，为了拥有一致的命名约定），因为大多数ORM允许这样做。 p>

对于其他人，在数据库模式上尽你所能：在适当的时候进行“软更改”，例如添加新字段或索引，不应该破坏在数据库上运行的现有代码（如果这是你不能的主要原因）改变架构）。

Answer 7

  

它需要保持各种各样的方式   的原因。

我不相信，但这并不重要。在数据库级别管理它非常简单。 （但简单并不一定意味着 easy 。）

可更新视图实现逻辑数据独立性。构建可更新视图，使应用程序代码无法判断它是在读取还是编写视图或基表。

这些可更新视图将应用程序代码与基表结构隔离开来。现在您可以自由修复设计。更改基表时，请更改视图以使其行为保持一致。

至于你是否可以使用ORM来创建一个好的数据模型而不改变设计糟糕的数据库，我会说，“不要指望它。”