ORM自动创建表违反了DBA首选项

Question

我正在使用ORM从模型类中自动创建表。我以一种对应用程序来说很自然的方式命名类及其字段。然后，ORM对表和列使用相同的名称，并自动生成其他对象的名称，如ORM完全抽象的约束和序列。

我没有声明应该如何命名表，列等。我把它留给ORM来决定。从应用程序的角度来看，我认为这很有道理。

我的团队的DBA不喜欢这一点。 DBA表示，如果表“A”中的列“B”对表“X”中的字段“Y”具有外键约束，则名称必须为“A.X_Y”而不是“ AB”。 DBA说这是命名外键的“正确”方式，因此ORM将错误地命名为。我熟悉的两个ORM引擎都允许将类/字段名显式映射到表/列名，因此我知道可以在不更改类的情况下容纳DBA。

我的问题是，实际上，这样做（显式映射名称）必然会引入一个额外的实体（即新配置文件/部分，新代码）或耦合（即导入，装饰器，应用程序中可能不存在的注释）？ ORM设计各不相同，所以我认为不同引擎的答案可能不同。

如果对此的答案几乎普遍是肯定的，那么我认为DBA应该为了提高生产率而对ORM产生一个好的论据，关于数据库为满足应用程序需求而存在的逻辑，而不是另一种方式。关于这一点的评论也是受欢迎的。

请注意，我不是要求有关如何命名类/字段/表/列的具体建议。

Answer 1

不，显式映射名称不会创建额外的实体或耦合;它定义了您的DBA决定适合其数据库的策略和流程。我也会争辩说，你的逻辑有点倒退;应用程序的存在是为了满足数据库的需求。任何公司建立的软件都存在于服务/填充/呈现数据库中存在的数据，而不是相反。

考虑一下;随着需求和技术的变化，随公司所做任何事情的软件都会发生变化，并随着标准和复杂性的发展而变得重构。但是，存储在数据库中的数据不会;即使模式发生变化/发展，基础数据也会发生变化，如果有的话。

Answer 2

  

ORM设计各不相同，所以我认为不同引擎的答案可能不同。

你就在这里。根据ORM，明确指定field-＆gt;列映射可能（或可能不）以配置条目，注释，属性等形式引入额外的实体。尽管如此，这是面包和黄油（或者我应该说ORM引擎的基础知识，因此处理这些映射通常不会增加明显的开销。

我觉得你绝对不能将它用作反对显式命名表，列等的参数。通常你会有另一个使用相同数据库的应用程序。应用程序生成的默认名称可能对该应用程序完全没有意义。我会让DBA决定数据库工件的正确命名，并在我的应用程序中调整映射到我的域模型。在所有这些之后，ORM增加了价值。

Answer 3

编码标准存在是有原因的 - 如果我是DBA，我可能会建议使用ORM而不进行修改的生产力优势应该以可维护性的名义产生。

这是一个权衡问题：如果根据公司标准命名外键列的额外努力是最小的（并且在我使用的大多数ORM中，它都是），我就是这样做的。

如果你的ORM让它变得非常困难，我会向DBA解释这是一个与他习惯的架构不同的架构 - 使用ORM意味着很少有任何手工SQL编写 - 所有这些都是由ORM自动创建，因此放宽编码标准是有意义的。