数据字典还是ORM？

Question

我正在为一个相当复杂的商业web应用程序替换框架。我们的应用程序运行在LAMP平台上，新的框架将是CodeIgniter。在我的框架设计研究中的一个扩展--我决定研究ORM，我以前从未做过ORM，我想知道它对我们的应用程序是否有价值。然后我偶然发现了一个非常有趣的博客文章，名为“为什么我不使用ORM”，这个博客似乎证实了我对使用ORM的许多担忧，它还提供了一个类似于我已经计划的解决方案。

通过“数据字典”，我计划使用“数据库程序员”博客中的这个定义：

包括我自己在内的许多人都使用“数据字典”一词来表示描述应用程序表的一组单独的表。“数据字典”包含列名、类型和大小等信息，但也包含描述性信息，如标题、标题、主键、外键，以及关于如何显示字段的用户界面提示。

因此，在选择“数据字典”而不是ORM时，我可能会表现出确认偏见，不管以下是我厌倦ORM的原因：

1. 我以前从未使用过ORM，我对它不太了解。
2. 这个框架需要构建得相当快，我的老板几乎没有时间，我需要开发一个可以顺利升级到更现代框架的工作应用程序。
3. 我的老板已经认为我已经完成了这个框架的工程(相信我，我并不接近这个框架)，并且偏执于这个框架阻止我们做我们需要做的事情，并制造出我们无法在规定的时间内解决的错误。到目前为止，我在说服他改变是好的方面做得很差，我不是一个非常有效率的推销员，虽然其他的开发人员可以帮助我，但老板仍然需要很多的保证。
4. 我们的旧框架是程序性的，我们的代码是PHP，我们的开发人员非常了解SQL。奥姆会是个很大的变化。
5. 我们的数据库有几十个表，其中许多在一个相当旧的服务器上运行着数十万个条目。在过去，我们被重复轮询数据库的代码烧录，而不是一次执行一个查询来提取所有需要的数据。用手工编码的SQL来避免这个问题是非常直接的。对于我来说，确保在必要的地方使用ORM总是发生这种情况是一个巨大的未知数，而且似乎是有风险的。

无论如何，数据字典的解决方案对我来说似乎很有希望，因为这篇博客文章“使用数据字典”似乎提供了许多有用的特性和一些新框架的需求。以下是我选择数据字典解决方案的原因：

1. 在表行上实现访问控制规则本身将是非常宝贵的。
2. 自动生成数据库更改、文档和模式检查也很有用。
3. 该框架的一个要求是通用数据历史/审核功能，它可以应用于应用程序中的任何子功能。提供这样的功能本质上需要数据字典或等效项。历史记录必须具有有关数据库中的结构和数据类型的详细信息。
4. 我们的系统拥有各种各样的数据类型，如果将它们作为应用程序中的正式类型来处理，这些数据类型将更合适。首先，HTML片段(在我们的数据中有很多，它们是必需的)需要被编码为实体，在其他情况下解码为HTML，在某些情况下解析链接和图像，并始终验证其正确性。此外，还有日期、度量、货币和其他各种字段，这些字段可以在代码中明确定义如何操作这些数据。

我想要实现的数据字典思想将是在不同的PHP文件中的一系列对象，并且会有大量的OOP，但是它将作为一种非常类似于“数据库程序员”博客中的数据字典概念的方式使用。它将是整个框架的完整数据库模式的单一源定义。

现在我的问题是，我是忽略了ORM的价值，还是在这种情况下，数据字典是适合这项工作的工具？

Answer 1

我认为，如果您正在做出初步的体系结构决策，而不是重构现有的应用程序，您的问题会更有趣。在您的问题中，我没有看到有一个断言可以提出ORM中的设计可以解决的问题；但是有几个问题会产生。如果两个主要的利益相关者群体(所有者和其他开发人员)对更传统的设计比较满意，那么在我看来，ORM将向上游游去。

我可以想象，当查询缓慢或事务锁定问题开始出现时(可能是不值得的)认可会与ORM相关联。更不用说对开发计划的影响了。为什么要创造一个无法量化的风险因素？

Answer 2

我认为你对你的情况做了很好的分析。您知道为什么选择数据字典方法。那就去吧。

稍后你可能会重新考虑。如果是这样的话，那么使用数据字典和ORM并行开发应该没有问题。这两种技术并不是相互排斥的。

如果您不喜欢混合不同技术的想法:坚持扎实的OOP设计，将域逻辑和数据访问分离开来，那么切换到ORM应该不会那么痛苦，或者至少是可能的。

祝好运!