表命名困境：单数与复数名称
学术界认为，表格名称应该是它们存储属性的实体的单数。
我不喜欢任何需要围绕名称的方括号的T-SQL，但我已将Users表重新命名为单数，永远判断使用表的人有时必须使用括号。
我的直觉是，用单数来保持是更正确的，但我的直觉是括号表示不喜欢的东西，例如列名中有空格等等。
我应该走还是留？
就“标准”而言，其他人已经给出了相当好的答案，但我只是想补充一点......“用户”（或“用户”）实际上可能不是表中数据的完整描述？ 并不是说你应该对表名和特殊性过分疯狂，但可能像“Widget_Users”（其中“Widget”是你的应用程序或网站的名称）更合适。
我有同样的问题，并在阅读所有答案后，我绝对留在SINGULAR，理由：
原因1 （概念）。 你可以想像包含苹果的袋子，比如“AppleBag”，如果包含0,1或者一百万个苹果，它并不重要，它总是一样的包。 表格就是这样，容器，表格名称必须描述它包含的内容，而不是包含多少数据。 此外，复数概念更多地是关于口语（实际上是确定是否存在一个或多个）。
原因2 。 （方便）。 用单数名称比用复数名称更容易。 对象可以有不规则的复数或不复数，但总会有单数（除了少数例外，如新闻）。
原因3 。 （美学和秩序）。 特别是在主细节情景中，这会更好，按名称更好地排列，并且具有更多的逻辑顺序（Master first，Detail second）：
相比：
原因4 （简单）。 放在一起，表名，主键，关系，实体类...更好地意识到只有一个名称（单数）而不是两个（单数类，复数表，单数字段，单数复数master-detail .. 。）
Customer Customer.CustomerID CustomerAddress public Class Customer {...} SELECT FROM Customer WHERE CustomerID = 100 一旦你知道你正在处理“客户”，你可以肯定你会用同一个词来满足你所有的数据库交互需求。
原因5 。 （全球化）。 世界变得越来越小，你可能有一个不同国籍的团队，并不是每个人都有英语作为母语。 对于非本地英语程序员来说，更容易想到“存储库”而不是“存储库”，或者避免他们键入“状态”而不是“状态”。 使用单数名称可以减少由错别字造成的错误，避免花费额外的时间思考“是孩子还是孩子？”，从而节省时间，从而提高生产力。
原因6 。 （为什么不？）。 它甚至可以节省您的写入时间，节省磁盘空间，甚至让您的电脑键盘持续更多！
SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100 SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100 你已经保存了3个字母，3个字节，3个额外的键盘命中:)
最后，您可以将这些名称命名为保留名称：
或者使用臭名昭着的方括号[User]
Joe Celko在其着作“SQL编程风格”一书中建议，集合（例如表格）应以复数形式命名，而标量数据元素（例如列）应以单数形式命名。
他引用ISO-11179-4作为元数据命名的标准，该标准支持这一指导原则。
让我争论为什么这是有道理的。
args 。 args恰好多，因为他们可以容纳0,1，以及数以百万计的参数。 for every student in students迭代它们，而不是for every student in students for every s in student 。 您从一组学生中选择一部分学生。 您不会从学生中选择一部分学生。 这是正确命名的概念性原因。 揭穿谬误。 最流行的答案说
原因1 （概念）。 你可以想像包含苹果的袋子，比如“AppleBag”，如果包含0,1或者一百万个苹果，它并不重要，它总是一样的包。 表格就是这样，容器，表格名称必须描述它包含的内容，而不是包含多少数据。 此外，复数概念更多地是关于口语（实际上是为了确定是否存在一个或多个），表格不打算由人读取。
让我们转换AppleBag => BagOfApples。 现在，同样的“概念”的说法表示，服用点对面本身，我们看到苹果S和因此答案一定是复数 ！
这是因为这个****没有任何概念。 它甚至不能推断英语，简单的逻辑。 用英语，一个BagOfApples != AnApple ！
“Bag包含0,1，...数百万”苹果的论点只是证明集合必须被称为“苹果”，类似Java参数或stackoverflow.com/posts 。 不知何故，文明的敌人设法得出结论，单数必须在这里使用。 帖子只是一个文件夹。 为什么它应该是复数？
让我们教先生吧。 Artuwood的一些逻辑： folder is a folder and must describe what it contains, not how much data it contains 。
事实上，如果你开始认为你意识到apple contains apple无稽之谈。 真正的概念是Bag contains Apples 。 要么我们命名我们的包装袋（特定种类），或者想一想它包含的是什么，苹果（那些肮脏的混蛋试图减少这个数字问题，但我们是在苹果之后，而不是它们的数量）。 是的，如果我们将包装器抽象出来，我们意识到我们在Apples之后，它包含了什么。 我们获取并迭代Bag或Apples，而不是Apple。
原因2 。 （方便）。 用单数名称比用复数名称更容易。 对象可以有不规则的复数或不复数，但总会有单数（除了少数例外，如新闻）。
客户订单用户状态新闻
他谈论哪种便利？ 让我们指出，复数比单数更简单。
原因3 。 （美学和秩序）。
Aestetics就在我们这边。 和他一样，这很简单。 我们只是声称这一点，这就是转换表所需的全部内容。
原因4 （简单）。 放在一起，表名，主键，关系，实体类...更好地意识到只有一个名称（单数）而不是两个（单数类，复数表，单数字段，单数复数master-detail .. 。）
我是否仅仅为了简单而看到，一切都必须变得单一？ 是的，忘记使用英语的复数。 它会让事情变得更简单。
事实上，在许多语言中，性关系到所有的事物，而不仅仅是男孩和女孩。 我注意到它简化了参考。 当我用俄语说“狐狸，狗和狼”，然后说“他”时，它毫不含糊地表示我是指“狼”，因为“狐狸”和“狗”是“她”。 现在你认为有助于减少歧义的区别创造了它。 怎么会这样？
可能的逻辑是“让我们用我们的语言来保持任意构造，并通过删除有意义的规则来强化这种混乱”。 是的，在逻辑要求复数时使用单数的建议，同时保持将不适当的属性（如性别）附加到不适当的项目上是在我们疯狂的世界中追求废话。
作为
SELECT activity.name读取比SELECT activities.name更好
您可能需要SELECT student.name FROM students as student
好的，这里可能是参数：如果table是复数，table的别名如何是单数？ 好的，这是有道理的。 但是说列（对象的属性）是单数的，因此，对象集合也必须是单数的，是无稽之谈。
原因5 。 （全球化）。 世界变得越来越小，你可能有一个不同国籍的团队，并不是每个人都有英语作为母语。 对于非本地英语程序员来说，更容易想到“存储库”而不是“存储库”，或者避免他们键入“状态”而不是“状态”。 使用单数名称可以减少由错别字造成的错误，避免花费额外的时间思考“是孩子还是孩子？”，从而节省时间，从而提高生产力。
为什么像我这样的其他非母语人士为了简单化和国际化而购买废话？ 为什么不改进我们的英语并保持逻辑一致？ 毕竟，在这种情况下理解语言要容易得多。
否则，为了简单起见，我们也应该放弃动词，文章，形容词，只用名词说话。 如果我们将言语限制在moooo而不是其他任何东西，那么动物能够说英语也会更简单（也更有效）。 这样我们实现了更广泛的国际化。
原因6 。 （为什么不？）。 它甚至可以节省您的写入时间，节省磁盘空间，甚至让您的电脑键盘持续更多！
这个观点支持我们为什么在人类交流中也应该放弃复数。 不，不是moooo, mo moo, moo moo ，我们会说I, III, III, II 。 比单独提案短得多。
单数唯一有意义的论据是表格是一组非常特殊的对象。 表是一个类 ！ 是的，它包含特定类型的所有对象，我们使用单数来表示类名。 类Dog包含所有的狗。 什么是dog1？ 它是一只狗。 另一方面，用户将表格作为集合来处理。 他们添加/删除项目收集，我们使用复数收集。
上一篇: Table Naming Dilemma: Singular vs. Plural Names
下一篇: What is the most efficient/elegant way to parse a flat table into a tree?