database - 数据字典还是ORM？

Question

我正在为一个相当复杂的业务web应用程序替换框架。我们的应用程序运行在一个lamp平台上，在我的框架设计研究中，新框架将是CodeIgniter.的一个扩展，我决定研究orm，我以前从未做过orm，我想知道它对我们的应用程序是否有价值。然后我偶然发现了一篇非常有趣的博客文章，题为"Why I Do Not Use ORM."这篇博客似乎证实了我对使用orm的许多担忧，而且它还提出了一个类似于我已经在计划的解决方案。
根据“数据字典”，我计划使用"The Database Programmer"博客中的定义：
包括我在内的许多人使用“数据字典”一词来表示描述应用程序表的一组单独的表。数据字典包含诸如列名、类型和大小等信息，还包含诸如标题、标题、主键、外键等描述性信息，以及向用户界面提示如何显示字段的提示。
因此，在选择“数据字典”而不是ORM时，我可能会表现出确认偏差，不管我厌倦ORM的原因是什么：
我以前从没用过orm，我不太了解它。
这个框架需要建立得相当快，我的老板几乎没有时间，我需要产生一个工作的应用程序，以便顺利升级到一个更现代化的框架。
我的老板已经认为我对这个框架的设计过度了（相信我，我离这个还差得远），并且偏执于这个框架阻止我们做我们需要做的事情，并且制造出我们在需要的时间内无法解决的错误。到目前为止，我在说服他改变是好的方面做得很差，我不是一个非常有效的销售人员，虽然其他开发人员可以帮助我，但老板仍然需要很多保证。
我们的旧框架是过程性的，我们的代码是php，我们的开发人员非常了解sql。ORM将是一个巨大的变化。
我们的数据库有几十个表，很多表都有几十万个条目在一个相当旧的服务器上运行。在过去，我们已经被代码烧焦了，这些代码在循环中重复轮询数据库，而不是一次执行一个查询来同时提取所有需要的数据。用手工编码的sql避免这个问题是相当直接的。对于我来说，确保这一切总是在ORM需要的时候发生，这是一个巨大的未知数，似乎是有风险的。
无论如何，数据字典的解决方案对我来说似乎非常有希望，因为这篇博客文章"Using A Data Dictionary"似乎提供了许多有用的特性，有些特性是新框架的要求。下面是我选择数据字典解决方案的原因：
在表行本身上实现访问控制规则是非常有价值的。
自动生成数据库更改、文档和模式检查也很有用。
框架的一个需求是一个通用的数据历史/审计特性，它可以应用于我们应用程序中的任何子特性。基本上需要一个数据字典或等效工具来提供这样的特性。历史记录必须包含有关数据库中的结构和数据类型的详细信息。
我们的系统拥有各种各样的数据类型，如果将它们作为应用程序中的正式类型来处理，这些数据类型将得到更正确的处理。首先，在某些情况下，需要将html片段（其中我们的数据中有许多片段是必需的）编码为实体，在其他情况下解码为html，在某些情况下解析为链接和图像，并始终验证其正确性。然后是日期、度量、货币和各种其他字段，这些字段可以从代码中明确定义如何操作这些数据中受益。
我想实现的数据字典的概念是在单独的php文件中的一系列对象，会有很多oop，但是它的使用方式与“数据库程序员”博客中的数据字典概念非常相似。它将是整个框架的完整数据库模式的单一源定义。
现在我的问题是，我是忽略了orm的价值，还是在这种情况下，数据字典才是合适的工具？

Answer 1

我认为，如果你正在做一个初步的架构决策，而不是重构现有的应用程序，那么你的问题会更有趣。我看不出你的问题中有一个断言暗示了在orm中设计可以解决的问题；但是它会创建几个断言。如果两个主要的利益相关者群体（所有者和其他开发人员）对更为传统的设计更为满意，那么在我看来，orm将向上游游动。
我可以想象，一旦查询速度变慢或事务锁定问题开始出现，ORM就会得到（可能是不应该得到的）认可。更不用说对开发进度的影响了。为什么要建立一个无法量化的风险因素？