实体名称与表名称

时间:2009-12-04 09:19:45

标签: database oop architecture orm

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

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

我想将实体命名为更有意义。像TB_CUST只是客户或客户实体。当然会有一个注释指向其表名。

但DBA和一个人的程序员,不想要这样的名字。他希望实体名称与表名完全相同。他说他必须记住两个名字,这将是困难和混乱的。我不得不说他不太熟悉OOP的原则。

但是如果像[{1}}这样的实体名称应该有TP_COMP_CARSGet TP_COMP_CARS之类的方法名称..我认为这是不可读和难看的。

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

提前谢谢

7 个答案:

答案 0 :(得分:11)

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

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

答案 1 :(得分:0)

谁将主要使用新代码?那个人应该决定命名惯例恕我直言。

我个人当然会选择你的解决方案,因为如前所述,如果你使用ORM,你不需要经常直接点击数据库。

答案 2 :(得分:0)

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

答案 3 :(得分:0)

两个不同域中使用的命名约定根本不对齐。例如,Java有一个非常明确的 Class 名称和 field 名称的规则/约定,其中大写是重要的。通常,您的应用程序可能被移植到具有不同命名标准的完全不同的数据库,要求Business Logic中的名称与数据库中的名称对齐是不合理的。考虑稍微复杂的映射,一个实体可能不对应一个表。

而且,真的,来吧......

 Customer == TB_CUST

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

答案 4 :(得分:0)

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

答案 5 :(得分:0)

如果数据库中有500个表 - 您已经遇到了将这些名称保持原状的挑战。希望你有元数据和一些图形模型更有意义地描述它们。

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

如果没有办法将这两组500个表连接在一起 - 那么你就有3个问题。考虑在ORM中调试查询的性能,并使用他无法识别的名称转到DBA。考虑一下精心设计的名称 - 当您创建直接命中数据库的报表时,必须忽略这些名称。

所以,我会非常努力地使用ORM中的数据库名称。但我会调整一些事情:

  • 如果名称太神秘而无法理解 - 我会与DBA合作改进其名称。转换为更好名称的简单方法是通过视图。理想情况下,你最终摆脱原来令人困惑的名字。
  • 从下划线更改为camelcase等不应被视为对名称的更改 - 它只是对分隔符的更改。因此,请使用适合您语言的名称。
  • 数据库前缀可能会被删除 - 它们实际上只是已经“非规范化”并嫁接到名称上的表名的属性。如果它们表明模型的一个子部分,它们可能是必要的,以避免重复,但通常可能同样重要。

答案 6 :(得分:-1)

“我必须说他不太熟悉OOP的原则。

但是在像TP_COMP_CARS这样的实体名称的情况下,应该有方法名称,如Get TP_COMP_CARS或SaveTP_COMP_CARS ..我认为这是不可读和丑陋的。

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

IT系统管理的内容与“OOP原则”完全无关。

同样适用于“标准”“getter and setter”方法的名称:这些只是协议和约定,而不是“OOP原则”。

问题是代码的某种“人体工程学”(因此也就是自我记录的价值)。

确实getTP_COMP_CARS看起来很丑陋(尽管不是,正如你声称的那样,“不可读”)。如果你开始坚持“更现代”的命名约定,那么就必须有某个人必须维护同义名称之间的映射。 (并且不正确的是,诸如TP_COMP_CARS之类的名称比完整的“自然语言单词”名称更少自我记录:通常这样的名称是由非常小的助记词组构成的,这些助记词一遍又一遍地使用具有相同的含义,让任何人都能记住它们非常容易。)

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

从现在起二十年后,人们会称这些天我们使用的命名惯例为“脑de”。