实体名称与表名称答案

【问题标题】：Entity names vs table names实体名称与表名称
【发布时间】：2009-12-04 09:19:44
【问题描述】：

我们将在旧数据库上开发一个新系统（使用 .NET C#）。大约有 500 个表。我们选择为我们的数据访问层使用 ORM 工具。问题在于实体的 namig 约定。

数据库中的表的名称类似于 TB_CUST - 包含客户数据的表，或 TP_COMP_CARS - 公司汽车。 prefix 的第一个字母定义模数，第二个字母定义它与其他表的关系。

我想给实体命名更有意义。就像TB_CUST 只是客户或客户实体。当然会有注释指向它的表名。

但是 DBA 和程序员合二为一，不想要这样的名字。他希望实体名称与表名称完全相同。他说他必须记住两个名字，这将是困难和混乱的。不得不说他对OOP的原理不是很熟悉。

但是对于像TP_COMP_CARS 这样的实体名称，应该有像Get TP_COMP_CARS 或SaveTP_COMP_CARS 这样的方法名称。我认为这是不可读和丑陋的。

所以请告诉我你的意见。谁是对的，为什么。

提前谢谢你

【问题讨论】：

标签： database oop architecture orm

【解决方案1】：

ORM 工具的整体理念是避免记忆数据库对象的需要。我们通常创建一个包含所有表名和列名的数据库类，因此不需要记住任何内容，ORM 应该将数据库“名称”映射到普通实体。

虽然是主观的，但在我看来你是对的，他是错的......

【讨论】：

+1 这就是 ORM 的重点：摆脱 Braindead 表命名约定 :)
这对现有的 DBA/程序员来说有些痛苦，他有自己的美好世界，而对他来说，这就是变化。但在这种情况下，我更看重在业务逻辑中精心挑选的域名，而不是为他节省一些工作。
+1 - 我还要补充一点，ORM 工具意味着您可以开发应用程序层，而无需硬编码确切的表名和列名。存储过程和硬编码的 SQL 使重构数据变得困难。在应用层很好地使用 ORM 和类型安全的实体对象可以更容易地重构数据。

【解决方案2】：

谁将主要使用新代码？该人应该决定命名约定恕我直言。

我个人当然会选择您的解决方案，因为正如已经提到的，如果您使用 ORM，则不需要经常直接访问数据库。

【讨论】：

我不同意第一部分。如果要处理代码的人发生变化怎么办？
看，我是第一个选择更改名称以适应范式的人。我也只是想指出硬币的这一面。不过，我并不坚持这一点。我希望我的观点不会受到更多负面影响:-)
+1 为什么要投反对票？人刚刚发表了他的意见，这正是你的问题。错误信息可能会被否决，但分歧不应被否决。

【解决方案3】：

作为一种折衷方案，您可以使用 TB_CUST 之类的名称，直接与数据库进行操作，然后使用 Customer 之类的名称作为您的数据传输对象。编写好的代码涉及创建您可能正在使用的任何数据源的抽象。在你的代码中使用GetTB_CUST() 有点像在整个地方点缀GetTB_CUSTFromThatSQLDatabaseWeHave()。

【讨论】：

【解决方案4】：

我个人讨厌这样的表名，但它是一个遗留系统，我确信 DBA 不想重命名这些表。重命名表可能是一种选择。您只需要创建表示旧表名的视图，以便您的旧系统在开发新系统时继续运行。如果这不是一个选项，您可以使用 ORM 将表名称映射到实体名称。或者，您可以在数据访问层中抽象出您的 ORM，并在您的域模型中定义好的实体名称，让您的 DAL 进行名称转换。

【讨论】：

【解决方案5】：

两个不同域中使用的命名约定根本不一致。例如，Java 为 Class 名称和 field 名称定义了非常明确的规则/约定，其中大写很重要。通常，您的应用程序可能会移植到具有不同命名标准的完全不同的数据库中，要求业务逻辑中的名称与数据库中的名称对齐是不合理的。考虑一个稍微复杂一点的映射，一个 Entity 可能不对应一个 Table。

而且，真的，来吧......

 Customer == TB_CUST

这并不难！我和你在一起，使名称在代码中有意义并在 ORM 中映射。 DBA/程序员的学习不应该那么痛苦，我猜这是在预期中感觉比现实更糟糕的事情之一。

【讨论】：

那么 GC_SU 和 S_OE 或 TB_FAKOE 呢？我不知道里面有什么:-)
这正是您应该从数据库中删除原始名称的原因。如果需要查找一些过时的文档来了解某个字段的含义，那么您在编码时很可能会出错。因此，您可以将 ORM 映射视为有关字段含义的实际文档。好多了。

【解决方案6】：

如果数据库中有 500 个表 - 您已经面临保持这些名称正确的挑战。希望您拥有元数据和一些更有意义地描述它们的图形模型。

当您创建下一个 500 个 ORM 对象时，您将面临另一个挑战。即使你给他们起有意义的名字，但仍然太多了，不能真正希望一切都是显而易见的。所以，现在你有两个问题。

如果无法将这两组 500 个表链接在一起 - 那么您就有 3 个问题。考虑调试 ORM 中查询的性能，并使用他不认识的名称去找 DBA。考虑一下您精心设计的名称 - 当您创建直接访问数据库的报告时必须忽略这些名称。

所以，我会非常努力地在 ORM 中使用数据库名称。但我会调整一些东西：

如果一个名字太神秘而无法理解 - 我会与 DBA 一起改进它的名字。过渡到更好名称的一种简单方法是通过视图。理想情况下，您最终会摆脱最初令人困惑的名称。
从下划线更改为驼峰等不应被视为更改名称 - 它只是更改分隔符。因此，请为您的语言使用适当的名称。
数据库前缀可能会被删除——它们实际上只是表名的属性，已被“非规范化”并移植到名称上。如果它们指示模型的一个子部分，则它们可能是必要的以避免重复，但通常可能同样重要。

【讨论】：

【解决方案7】：

“不得不说他对OOP的原理不是很熟悉。

但是对于像 TP_COMP_CARS 这样的实体名称，应该有像 Get TP_COMP_CARS 或 SaveTP_COMP_CARS 这样的方法名称。我认为这是不可读和丑陋的。

所以请告诉我你的意见。谁是对的，为什么。”

您的 IT 系统管理的事物的名称与“OOP 原则”完全无关。

“标准”“getter 和 setter”方法的名称也是如此：它们只是协议和约定，而不是“OOP 原则”。

问题在于代码的某种“人体工程学”（因此也是自我记录价值）。

确实 getTP_COMP_CARS 看起来很丑（尽管不是，正如你所说的，“不可读”）。同样，如果您开始遵守“更现代”的命名约定，那么一定会有人在某个地方维护同义名称之间的映射。（而且，像 TP_COMP_CARS 这样的名称比完整的“自然语言单词”名称更不具有自文档性是不正确的：通常这些名称是由一组非常小的助记词构成的，这些词被一遍又一遍地使用，具有相同的含义，让任何人都可以轻松记住它们。）

这没有对错。在我们现在居住的那些日子之前，这样的名字是通常的惯例。至少，这些名称通常具有不区分大小写的好处，而不是所谓的“更现代”系统强加给我们的无脑（因为区分大小写）命名规则。

20 年后，人们也会将我们现在使用的命名约定称为“脑死亡”。

【讨论】：