首页 文章

表命名困境：奇异与多个名称[关闭]

提问于
浏览 次
1236

学术界认为表名应该是他们存储属性的实体的单数 .

我不喜欢任何需要方括号的T-SQL，但我已经将 Users 表重命名为单数，永远判断那些使用该表的人有时必须使用括号 .

我的直觉是，保持单数是更正确的，但我的直觉也是括号表示不受欢迎的人，如列名，其中有空格等 .

我应该走还是留？

sql sql-server naming-conventions

30 回答

  • 6

    我不喜欢复数表格名称，因为英语中的一些名词不可数（水，汤，现金）或者当你使它成为可数时意义改变（鸡与鸡，肉与鸟） . 我也不喜欢使用表名或列名的缩写，因为这样做会为已经陡峭的学习曲线增加额外的斜率 .

    具有讽刺意味的是，由于USER (Transac-SQL)，我可能会将 User 作为例外并将其称为 Users ，因为我也不会这样做 .

    我还想将所有ID列命名为 Id ，而不是 ChickenId 或 ChickensId （复数人员对此做了什么？） .

    所有这一切都是因为我对数据库系统没有适当的尊重，我只是从习惯和懒惰中重新应用来自OO命名约定的单一技巧 - 小马知识，如Java's . 我希望有更好的IDE支持复杂的SQL .

    回复于
  • 7

    我是单个表名的粉丝，因为他们使用CASE语法使我的ER图更容易阅读，但通过阅读这些回复，我感觉它从未如此流行？我个人喜欢它 . 有一个很好的概述，示例说明当您使用单数表名称时，模型的可读性，向您的关系添加动作动词以及为每个关系形成良好的句子 . 对于一个20表的数据库来说，这有点过分，但如果你有一个拥有数百个表和复杂设计的数据库，你的开发人员如何在没有良好可读图的情况下理解它？

    http://www.aisintl.com/case/method.html

    至于为表格和视图添加前缀，我绝对讨厌这种做法 . 在给予他们可能不良信息之前，根本不给任何人提供信息 . 任何浏览数据库对象的人都可以很容易地从一个视图中告诉一个表，但是如果我有一个名为tblUsers的表，由于某种原因我决定将来重组为两个表，并使用一个视图统一它们以防止破坏旧代码我现在有一个名为tblUsers的视图 . 在这一点上，我留下了两个没有吸引力的选项，留下一个以tbl前缀命名的视图，这可能会使一些开发人员感到困惑，或者强制使用另一个层，要么重写中间层或应用程序以引用我的新结构或名称viewUsers . 这否定了恕我直言的观点 Value 的很大一部分 .

    回复于
  • 5

    如果您使用对象关系映射工具或将来我建议 Singular .

    像LLBLGen这样的工具可以自动更正多个名称，例如用户到用户，而无需更改表名本身 . 为什么这很重要？因为当它被映射时你希望它看起来像User.Name而不是Users.Name，或者更糟糕的是我的一些旧数据库表命名tblUsers.strName，这在代码中只是令人困惑 .

    我的新经验法则是判断一旦它被转换成对象后它的外观 .

    我找到的一个表不适合我使用的新命名是UsersInRoles . 但总会有少数例外，即使在这种情况下它看起来也很好，如UsersInRoles.Username .

    回复于
  • 7

    我的看法是语义，取决于你如何定义容器 . 例如，“苹果袋”或简称为“苹果”或“苹果袋”或“苹果” .

    示例：“大学”表可以包含0个或更多个大学，“大学”表可以包含0个或更多个同事

    a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

    我的结论是，两者都很好，但你必须定义你（或与之交互的人）在引用表格时会如何处理; “x表”或“xs表”

    回复于
  • 16

    我也会选择 plurals ，并且由于前面提到的用户困境，我们采取了方括号方法 .

    我们这样做是为了在数据库体系结构和应用程序体系结构之间提供一致性，基本理解Users表是User值的集合，而代码工件中的Users集合是User对象的集合 .

    让我们的数据团队和我们的开发人员使用相同的概念语言（虽然并不总是相同的对象名称），可以更容易地在他们之间传达想法 .

    回复于
  • 11

    就“标准”而言，其他人已给出了相当不错的答案，但我只是想添加这个......“用户”（或“用户”）是否可能实际上并不是对表中所含数据的完整描述？并不是说你应该对表名和特性过于疯狂，但也许类似“Widget_Users”（其中“Widget”是你的应用程序或网站的名称）会更合适 .

    回复于
  • 8

    单数 . 我不买任何涉及最合乎逻辑的论据 - 每一个人认为他自己的偏好是最合乎逻辑的 . 无论你做什么都是一团糟，只需选择一个约定并坚持下去 . 我们试图将具有高度不规则语法和语义（正常的口语和书面语言）的语言映射到具有非常特定语义的高度规则（SQL）语法 .

    我的主要论点是，我不认为这些表是一个集合，而是作为关系 .

    所以， AppUser 关系告诉哪些实体是 AppUsers .

    AppUserGroup 关系告诉我哪些实体是 AppUserGroups

    AppUser_AppUserGroup 关系告诉我 AppUsers 和 AppUserGroups 是如何相关的 .

    AppUserGroup_AppUserGroup 关系告诉我 AppUserGroups 和 AppUserGroups 是如何相关的（即组的成员组） .

    换句话说，当我考虑实体以及它们如何相关时，我会以单数形式考虑关系，但当然，当我想到集合或集合中的实体时，集合或集合是复数 .

    在我的代码中，然后在数据库模式中，我使用单数 . 在文本描述中，我最终使用复数来提高可读性 - 然后使用字体等来区分表/关系名称和复数s .

    我喜欢把它看成是凌乱的，但却是系统的 - 这种方式总是会为我想表达的关系系统地生成名称，这对我来说非常重要 .

    回复于
  • 115

    我坚信在实体关系图中，实体应该用一个单数名称来反映，类似于一个单数的类名 . 实例化后，名称将反映其实例 . 因此，对于数据库，实体在制成表格（实体或记录的集合）时是复数形式 . 实体，用户被制成表用户 . 我同意其他人的观点，他们可能会建议用户名称可以改进为员工，或者更适用于您的场景 .

    这在SQL语句中更有意义，因为您从一组记录中进行选择，如果表名是单数，则读取不好 .

    回复于
  • 8

    表的SQL定义实际上是表的一个潜在行的定义，而不是集合的定义 . 因此，该定义中使用的名称必须指定行的类型，而不是集合的名称 . 喜欢复数的人，因为它在英语陈述中读得很好，需要开始更逻辑地思考，并查看实际使用表所涉及的所有逻辑和编程代码 . 这些注释中提到了几个使用单数表名称的非常好的理由 . 这些包括非常好的理由不使用多个表名 . “读得好”根本不应该是任何理由，特别是因为有些人可能会以不同的方式阅读这个想法 .

    回复于
  • 5

    我坚持使用 singular 表格和任何编程实体 .

    原因？事实上，英语中有不规则的复数，如老鼠⇒老鼠和绵羊⇒绵羊 . 然后，如果我需要一个集合，我只是使用鼠标或绵羊，继续前进 .

    它确实有助于多元化突出，我可以轻松地和编程地确定事物的集合将是什么样子 .

    所以，我的规则是：一切都是单数的，每个事物的集合都是单数的，附加一个s . 也帮助ORM .

    回复于
  • 9

    什么约定要求表具有单数名称？我一直认为这是多个名字 .

    用户将添加到Users表中 .

    本网站同意：
    http://vyaskn.tripod.com/object_naming.htm#Tables

    这个网站不同意（但我不同意）：
    http://justinsomnia.org/writings/naming_conventions.html

    正如其他人所说：这些只是指导方针 . 选择适合您和您公司/项目的惯例并坚持下去 . 在单数和复数之间切换或者有时缩写单词有时不会更加恶化 .

    回复于
  • 8

    这是一个简单的例子：

    SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

    与

    SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

    后者的SQL听起来比前者更陌生 .

    我投票给 singular .

    回复于
  • 13

    我更喜欢使用 uninflected 名词，在英语中恰好是单数 .

    改变表名的数量会导致拼写问题（正如许多其他答案所示），但选择这样做是因为表通常包含多行，因此在语义上也充满了漏洞 . 如果我们考虑一种基于案例（大多数情况下）会改变名词的语言，这一点就更加明显了：

    既然我们是一个什么样的表，为什么不使用属格呢？我们不会这样做，因为该表被定义为一个抽象容器，无论其状态或用途如何都存在 . 在没有精确和绝对语义原因的情况下改变名词是喋喋不休 .

    使用未反射的名词是简单的，逻辑的，规则的和与语言无关的 .

    回复于
  • 14

    恕我直言，表名应该像客户一样 plural .

    如果类名映射到Customers表中的行，则它们应该像Customer一样 .

    回复于
  • 216

    单数 . 我将调用一个包含一堆用户行表示对象'users'的数组，但该表是'用户表' . 将表视为只包含它所包含的行的集合是错误的，IMO;表是元数据，行集是分层附加到表，它不是表本身 .

    当然，我总是使用ORM，这有助于用多个表名写的ORM代码看起来很愚蠢 .

    回复于
  • 9

    表：复数

    users表中列出了多个用户 .

    型号：单数

    可以从用户表中选择单个用户 .

    控制器：复数

    http://myapp.com/users会列出多个用户 .

    无论如何，这是我对它的看法 .

    回复于
  • 22

    如果我们查看 MS SQL Server's 系统表，则Microsoft指定的名称在 plural 中 .

    Oracle的系统表在 singular 中命名 . 虽然其中一些是复数 . Oracle建议使用多个用户定义的表名 . 那也没有多大意义......毕竟，这些家伙是什么......博士学位？

    我确实记得在学术界，推荐是单数的 .

    例如，当我们说：

    select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

    也许b / c每个 ID 是从特定的一行中选出的......？

    回复于
  • 247

    我只使用名词作为拼写相同的表名，无论是单数还是复数：

    驼鹿鱼鹿飞机你裤子短裤眼镜剪刀种子后代

    回复于
  • 35

    可能的选择：

    • 重命名表SystemUser

    • 使用括号

    • 保留复数表名 .

    使用支架的IMO在技术上是最安全的方法，尽管它有点麻烦 . IMO是其中的6个，另外6个，你的解决方案实际上归结为个人/团队偏好 .

    回复于
  • 13

    我个人更喜欢使用复数名称来代表一个集合，它对我的关系思维来说只是“听起来”更好 .

    在这个时刻，我使用单数名称为我的公司定义数据模型，因为大多数工作人员对此感到更加舒适 . 有时你只需要让每个人的生活更轻松，而不是强加你的个人喜好 . （这就是我在这个帖子中的结果，以确定什么应该是命名表的“最佳实践”）

    在阅读了这个帖子中的所有争论之后，我得出了一个结论：

    无论每个人最喜欢的味道是什么，我都喜欢我的蜂蜜煎饼 . 但如果我正在为其他人做饭，我会尝试为他们提供他们喜欢的东西 .

    回复于
  • 184

    我实际上一直认为使用多个表名是流行的惯例 . 到目前为止，我一直使用复数 .

    我可以理解单数表名称的论点，但对我来说 plural 更有意义 . 表名通常描述表包含的内容 . 在规范化数据库中，每个表都包含特定的数据集 . 每行都是一个实体，该表包含许多实体 . 因此表名的复数形式 .

    一张汽车的 table 上有汽车的名称，每排都是一辆汽车 . 我承认，以 table.field 方式指定表和字段是最佳做法，并且具有单个表名更具可读性 . 但是在以下两个例子中，前者更有意义：

    SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

    老实说，我将重新考虑我对这个问题的立场，我将依赖于我正在开发的组织所使用的实际惯例 . 但是，我认为对于我的个人约定，我会坚持使用多个表名 . 对我而言更有意义 .

    回复于
  • 8

    服务器本身的系统 tables/views （ SYSCAT.TABLES ， dbo.sysindexes ， ALL_TABLES ， information_schema.columns 等）几乎总是复数 . 我想为了保持一致性，我会跟随他们的步伐 .

    回复于
  • 54

    我一直认为这是一个愚蠢的惯例 . 我使用多个表名 .

    （我相信该策略背后的理性是它使ORM代码生成器更容易生成对象和集合类，因为从单数名称生成复数名称比反之亦然更容易）

    回复于
  • 16

    这可能有点多余，但我建议保持谨慎 . 重命名表不一定是坏事，但标准化就是这样;一个标准 - 这个数据库可能已经“标准化”，但是很糟糕:) - 我建议一致性是一个更好的目标，因为这个数据库已经存在，并且可能它只包含2个表 .

    除非你能够标准化整个数据库，或者至少计划为此目的而努力，否则我怀疑表名只是冰山一角，专注于手头的任务，忍受命名不佳的物体的痛苦，可能在你的最大利益 -

    实用的一致性有时是最好的标准...... :)

    my2cents ---

    回复于
  • 11

    我认为使用单数是我们在大学里教的 . 但与此同时，您可能会争辩说，与面向对象编程不同，表不是其记录的实例 .

    由于英语中存在多种不规则现象，我认为我现在正倾向于支持单数 . 在德语中，由于没有一致的复数形式，情况甚至更糟 - 有时你无法判断一个单词是否为复数而没有前面的指定文章（der / die / das） . 而在中文中，无论如何都没有复数形式 .

    回复于
  • 29

    我有同样的问题，在阅读完这里的所有答案后，我绝对会留下奇异的理由：

    Reason 1 （概念）你可以想到包含像"AppleBag"这样的苹果的包，如果含有0,1或者一百万个苹果就没关系，它总是同一个包 . 表就是容器，表名必须描述它包含的内容，而不是它包含的数据量 . 另外，复数概念更多地是关于口语（实际上确定是否存在一个或多个） .

    Reason 2 . （方便） . 与复数名称相比，更容易得出奇异的名称 . 对象可以有不规则的复数或根本不是复数，但总是有一个单数（除了新闻之外的少数例外） .

    • 客户

    • 订单

    • 用户

    • 状态

    • 新闻

    Reason 3 . （审美和秩序） . 特别是在主 - 详细信息场景中，这更好地读取，按名称更好地对齐，并且具有更多逻辑顺序（Master first，Detail second）：

    • 1.订单

    • 2.OrderDetail

    相比：

    • 1.OrderDetails

    • 2.订单

    Reason 4 （简约）总而言之，表名，主键，关系，实体类......最好只知道一个名称（单数）而不是两个（单数类，复数表，奇异字段，单数 - 复数主 - 细节.. . ）

    • Customer

    • Customer.CustomerID

    • CustomerAddress

    • public Class Customer {...}

    • SELECT FROM Customer WHERE CustomerID = 100

    一旦您知道自己正在处理“客户”，就可以确定您将使用相同的单词来满足您的所有数据库交互需求 .

    Reason 5 . （全球化） . 世界变得越来越小，你可能拥有一个不同国籍的团队，而不是每个人都有英语作为母语 . 对于非母语英语程序员来说，比"Repositories"或"Statuses"而不是"Status"更容易想到"Repository" . 具有单一名称可以减少错别字引起的错误，节省时间而不必考虑"is it Child or Children?"，从而提高 生产环境 率 .

    Reason 6 . （为什么不？） . 它甚至可以节省您的写作时间，节省磁盘空间，甚至可以延长计算机键盘的使用寿命！

    • SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100

    • SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

    你已经保存了3个字母，3个字节，3个额外的键盘点击:)

    最后，你可以命名那些搞乱保留名称的人：

    • 用户> LoginUser，AppUser，SystemUser，CMSUser，...

    或使用臭名昭着的方括号[用户]

    回复于
  • 1475

    正如其他人在此提到的那样，约定应该是增加易用性和可读性的工具 . 不是折磨开发商的束缚或俱乐部 .

    也就是说，我个人的偏好是对表格和列使用单数名称 . 这可能来自我的编程背景 . 类名通常是单数，除非它们是某种集合 . 在我看来，我正在存储或阅读有问题的表中的个别记录，所以奇异对我来说是有道理的 .

    这种做法还允许我为那些存储我的对象之间的多对多关系的表保留多个表名 .

    我也试图避免在表格和列名中保留单词 . 在这里讨论的情况下，更有意义的是违背用户的单一约定，以避免需要封装使用User的保留字的表 .

    我喜欢以有限的方式使用前缀（tbl用于表名，sp_用于proc名称等），尽管许多人认为这会增加混乱 . 我也更喜欢CamelBack名称下划线，因为我总是在键入名称时最终命中而不是_ . 许多人不同意 .

    这是命名约定指南的另一个很好的链接：http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

    请记住，您的约定中最重要的因素是与相关数据库交互的人员是有意义的 . 在命名约定方面，没有“一环统治它们” .

    回复于
  • 62

    我总是使用单数，因为这就是我所教的 . 然而，在最近创建一个新架构时，我很长时间以来第一次主动决定维护这个约定只是因为......它更短 . 在每个表名的末尾添加's'对我来说似乎没有用，因为在每个表前面添加'tbl_' .

    回复于
  • 9

    我们运行类似的标准，当脚本我们要求[]围绕名称，以及适当的模式限定符 - 主要是它通过SQL语法对未来的名称争夺进行对冲 .

    SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

    这已经拯救了我们的灵魂 - 我们的一些数据库系统已经运行了10年，从SQL 6.0到SQL 2005 - 超过了预期的寿命 .

    回复于
  • 21

    我曾经在User表中使用“Dude” - 相同的短字符数，与关键字没有冲突，仍然是对通用人类的引用 . 如果我不担心可能会看到代码的闷头，我会保持这种方式 .

    回复于

相关问题