学术界认为表名应该是他们存储属性的实体的单数.
我不喜欢任何需要在名称周围使用方括号的T-SQL,但我已经将Users表重命名为单数,永远判断那些使用表的人有时必须使用括号.
我的直觉是,保持单数是更正确的,但我的直觉也是括号表示不受欢迎的人,如列名,其中有空格等.
我应该走还是留？
我有同样的问题,在阅读完这里的所有答案后,我肯定会留在SINGULAR,原因:
原因1(概念).你可以想到包含苹果的包如"AppleBag",如果包含0,1或者100万个苹果没关系,它总是相同的包.表只是容器,表名必须描述它包含的内容,而不是它包含的数据量.另外,复数概念更多地是关于口语(实际上确定是否存在一个或多个).
原因2.(方便).与复数名称相比,更容易出现奇异名称.对象可以具有不规则的复数或者根本不具有复数,但是总是具有单数(除了新闻之外的少数例外).
顾客
订购
用户
状态
新闻
原因3.(审美和秩序).特别是在主 - 详细信息场景中,这更好地读取,更好地按名称对齐,并且具有更多逻辑顺序(Master first,Detail second):
1.Order
2.OrderDetail
相比:
1.OrderDetails
2.Orders
原因4(简单).总而言之,表名,主键,关系,实体类......最好只知道一个名称(单数)而不是两个(单数类,复数表,奇异字段,单数 - 复数主 - 细节.. .)
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个额外的键盘点击:)
最后,您可以将那些与保留名称混淆的名称命名为:
用户> LoginUser,AppUser,SystemUser,CMSUser,...
或使用臭名昭着的方括号[用户]
如果您使用对象关系映射工具,或将来我建议使用Singular.
像LLBLGen这样的工具可以自动更正多个名称,例如用户到用户,而无需更改表名本身.为什么这很重要？因为当它被映射时你希望它看起来像User.Name而不是Users.Name,或者更糟糕的是我的一些旧数据库表命名tblUsers.strName,这在代码中只是令人困惑.
我的新经验法则是判断一旦它被转换成对象后它的外观.
我找到的一个表不适合我使用的新命名是UsersInRoles.但总会有少数例外,即使在这种情况下它看起来也很好,如UsersInRoles.Username.
就"标准"而言,其他人已给出了相当不错的答案,但我只想添加这个......"用户"(或"用户")是否可能实际上并不是表中所含数据的完整描述？并不是说你应该对表名和特异性过于疯狂,但也许类似"Widget_Users"(其中"Widget"是你的应用程序或网站的名称)会更合适.
我更喜欢使用未反射的名词,在英语中恰好是单数.
改变表名的数量会导致正交问题(正如许多其他答案所示),但选择这样做是因为表通常包含多行,因此在语义上也充满了漏洞.如果我们考虑一种基于案例(大多数情况下)调用名词的语言,这一点就更加明显了:
既然我们通常会对行做些什么,为什么不把这个名字放在指控的情况下呢？如果我们写的表比我们读的要多,为什么不把这个名字写成dative？这是一个表的东西,为什么不使用所有格？我们不会这样做,因为该表被定义为一个抽象容器,无论其状态或用法如何都存在.在没有精确和绝对语义原因的情况下改变名词就是喋喋不休.
使用未反射的名词是简单的,逻辑的,规则的和与语言无关的.
什么约定要求表具有单数名称？我一直认为这是多个名字.
用户将添加到Users表中.
本网站同意:http:
//vyaskn.tripod.com/object_naming.htm#Tables
该网站不同意(但我不同意):http:
//justinsomnia.org/writings/naming_conventions.html
正如其他人所说:这些只是指导方针.选择适合您和您公司/项目的惯例并坚持下去.在单数和复数之间切换或有时缩写单词有时不会更加恶化.
这个如何作为一个简单的例子:
SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"
与
SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"
后者的SQL听起来比前者更陌生.
我投票支持单数.
我坚信在实体关系图中,实体应该用一个单数名称来反映,类似于一个单数的类名.实例化后,名称将反映其实例.因此,对于数据库,实体在制成表格(实体或记录的集合)时是复数形式.实体,用户被制成表用户.我同意其他人的建议,可能会将用户名称改进为员工,或者更适用于您的场景.
这在SQL语句中更有意义,因为您从一组记录中进行选择,如果表名是单数,则读取不好.
我坚持使用单数表格和任何编程实体.
原因？事实上,英语中有不规则的复数,如老鼠⇒老鼠和绵羊⇒绵羊.然后,如果我需要一个集合,我只需使用鼠标或绵羊,然后继续前进.
它确实有助于多元化突出,我可以轻松地和编程地确定事物的集合将是什么样子.
所以,我的规则是:一切都是单数的,每个事物的集合都是单数的,附加一个s.也帮助ORM.
恕我直言,表名应该像客户一样复数.
如果类名映射到Customers表中的行,则类名应该像Customer一样.
单数.我不买任何涉及最合乎逻辑的论据 - 每个人都认为他自己的偏好是最合乎逻辑的.无论你做什么都是一团糟,只需选择一个约定并坚持下去.我们试图将具有高度不规则语法和语义(正常的口语和书面语言)的语言映射到具有非常特定语义的高度规则(SQL)语法.
我的主要论点是,我不认为这些表是一个集合,而是作为关系.
因此,AppUser关系告诉哪些实体AppUsers.
这种AppUserGroup关系告诉我哪些实体AppUserGroups
的AppUser_AppUserGroup关系告诉了我怎么AppUsers和AppUserGroups有关系.
这种AppUserGroup_AppUserGroup关系告诉我如何AppUserGroups和AppUserGroups相关(即群组成员).
换句话说,当我考虑实体及其相关性时,我会以单数形式考虑关系,但当然,当我想到集合或集合中的实体时,集合或集合是复数.
在我的代码中,然后在数据库模式中,我使用单数.在文本描述中,我最终使用复数来提高可读性 - 然后使用字体等来区分表/关系名称和复数s.
我喜欢把它看作是凌乱的,而是系统的 - 这种方式总是有一个系统生成的名称,我希望表达的关系对我来说非常重要.
我也会使用复数形式,并且由于上述用户困境,我们采取了方括号方法.
我们这样做是为了在数据库体系结构和应用程序体系结构之间提供一致性,基本理解Users表是User值的集合,而代码工件中的Users集合是User对象的集合.
让我们的数据团队和我们的开发人员使用相同的概念语言(尽管并不总是相同的对象名称)可以更容易地在它们之间传达想法.
我个人更喜欢使用复数名称来表示一组,它对我的关系思维来说只是"听起来"更好.
在这个时刻,我使用单数名称来为我的公司定义数据模型,因为大多数工作人员对此感到更加舒适.有时你只需要让每个人的生活更轻松,而不是强加你的个人喜好.(这就是我在这个帖子中的结果,以获得关于命名表的"最佳实践"的确认)
在阅读了这个帖子中的所有争论之后,我得出了一个结论:
无论每个人最喜欢的味道是什么,我都喜欢我的蜂蜜煎饼.但如果我正在为其他人做饭,我会尝试为他们提供他们喜欢的东西.
单数.我将调用一个包含一堆用户行表示对象'users'的数组,但该表是'用户表'.将表视为只包含它所包含的行的集合是错误的,IMO; 表是元数据,行集按层次结构附加到表中,而不是表本身.
当然,我总是使用ORM,并且用多个表名编写的ORM代码看起来很愚蠢.
我不喜欢复数表名,因为英语中的一些名词不可数(水,汤,现金),或者当你使它成为可数时意义改变(鸡与鸡,肉与鸟).我也不喜欢使用表名或列名的缩写,因为这样做会给已经陡峭的学习曲线增加额外的斜率.
具有讽刺意味的是,我可能会因为USER(Transac-SQL)而User异常并调用它,因为如果我不需要,我也不喜欢在表格周围使用括号.Users
我也喜欢来命名所有的ID列作为Id,而不是 ChickenId或ChickensId(什么做复数家伙怎么处理这件事？).
所有这一切都是因为我对数据库系统没有适当的尊重,我只是重新应用来自OO命名约定的单一技巧 - 小马知识,比如Java的习惯和懒惰.我希望有更好的IDE支持复杂的SQL.
我们运行类似的标准,当脚本我们要求[]围绕名称,以及适当的模式限定符 - 主要是它通过SQL语法对未来的名称争夺进行对冲.
SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'
这已经拯救了我们的灵魂 - 我们的一些数据库系统已经从SQL 6.0到SQL 2005运行了10多年 - 远远超过了预期的寿命.
我实际上一直认为使用复数表名是流行的惯例.到目前为止,我一直使用复数.
我可以理解单数表名称的论点,但对我而言,复数更有意义.表名通常描述表包含的内容.在规范化数据库中,每个表都包含特定的数据集.每行都是一个实体,表包含许多实体.因此表名的复数形式.
汽车的表将有名称的汽车和每一行都是汽车.我承认,以某种table.field方式指定表和字段是最佳做法,并且具有单个表名更具可读性.但是在以下两个例子中,前者更有意义:
SELECT * FROM cars WHERE color='blue' SELECT * FROM car WHERE color='blue'
老实说,我将重新考虑我对这个问题的立场,我将依赖于我正在开发的组织所使用的实际惯例.但是,我认为对于我的个人约定,我会坚持使用多个表名.对我而言更有意义.
表:复数
users表中列出了多个用户.
型号:单数
可以从用户表中选择单个用户.
控制器:复数
http://myapp.com/users会列出多个用户.
无论如何,这是我对它的看法.
该系统tables/views服务器本身(的SYSCAT.TABLES,dbo.sysindexes,ALL_TABLES,information_schema.columns,等)几乎总是复数.我想为了保持一致性,我会追随他们的领导.
我是单个表名的粉丝,因为他们使用CASE语法使我的ER图更容易阅读,但通过阅读这些回复,我感觉它从来没有流行起来？我个人喜欢它.有一个很好的概述,例子说明当您使用单数表名称时,模型的可读性,为您的关系添加动作动词以及为每个关系形成好的句子.对于一个20表数据库来说,这有点过分,但如果你有一个拥有数百个表和复杂设计的数据库,你的开发人员如何在没有良好可读图的情况下理解它？
http://www.aisintl.com/case/method.html
至于为表格和视图添加前缀,我绝对讨厌这种做法.在给予他们可能不良信息之前,根本不给任何人提供信息.任何浏览数据库对象的人都可以很容易地从视图中告诉表,但是如果我有一个名为tblUsers的表,由于某种原因我决定将来重组为两个表,并使用一个视图统一它们以防止破坏旧代码我现在有一个名为tblUsers的视图.在这一点上,我留下了两个没有吸引力的选项,留下一个以tbl前缀命名的视图,这可能会使一些开发人员感到困惑,或者强制使用另一个层,要么重写中间层或应用程序以引用我的新结构或名称viewUsers.这否定了恕我直言的观点价值的很大一部分.
如果我们查看MS SQL Server's系统表,它们的名称由Microsoft分配plural.
Oracle的系统表以命名singular.虽然其中一些是复数.Oracle建议使用多个用户定义的表名.他们推荐一件事并跟随另一件事并没有多大意义.这两个软件巨头的建筑师用不同的惯例命名他们的桌子也没有多大意义......毕竟,这些家伙是什么......博士？
我记得在学术界,这个建议是单数的.
例如,当我们说:
select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'
也许b/c每个ID都是从特定的一行中选出的......？
可能的选择:
重命名表SystemUser
使用括号
保留多个表名.
使用支架的IMO在技术上是最安全的方法,尽管它有点麻烦.IMO是其中的6个,另外6个,你的解决方案实际上归结为个人/团队偏好.
这可能有点多余,但我建议保持谨慎.重命名表不一定是坏事,但标准化就是这样; 一个标准 - 这个数据库可能已经"标准化",但是很糟糕:) - 我建议一致性是一个更好的目标,因为这个数据库已经存在,并且可能它只包含2个表.
除非你能够标准化整个数据库,或者至少计划为此目的而努力,否则我怀疑表名只是冰山一角,专注于手头的任务,忍受命名不佳的物体的痛苦,可能在你的最大利益 -
实际的一致性有时是最好的标准...... :)
my2cents ---
我的观点是语义,取决于你如何定义容器.例如,"苹果袋"或简称为"苹果"或"苹果袋"或"苹果".
示例:"大学"表可以包含0个或更多个学院,"大学"表可以包含0个或更多个同事
a "student" table can contain 0 or more students a table of "students" can contain 0 or more students.
我的结论是,两者都很好,但你必须定义你(或与之交互的人)在引用表格时会如何处理; "ax table"或"xs表"
正如其他人在此提到的那样,约定应该是增加易用性和可读性的工具.不是折磨开发商的束缚或俱乐部.
也就是说,我个人的偏好是对表格和列使用单数名称.这可能来自我的编程背景.类名通常是单数,除非它们是某种集合.在我看来,我正在存储或阅读有问题的表中的个别记录,所以奇异对我来说是有道理的.
这种做法还允许我为那些存储我的对象之间的多对多关系的表保留多个表名.
我也试图避免在表格和列名中保留单词.在这里讨论的情况下,更有意义的是,与用户的单一约定相反,以避免需要封装使用User的保留字的表.
我喜欢以有限的方式使用前缀(tbl用于表名,sp_用于proc名称等),尽管许多人认为这会增加混乱.我也更喜欢CamelBack名称下划线,因为在键入名称时我总是最后点击+而不是_.许多人不同意.
以下是命名惯例指南的另一个很好的链接:http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/
请记住,您的约定中最重要的因素是,与相关数据库交互的人员是有意义的.在命名约定方面,没有"一环统治它们".
我认为使用单数是我们在大学里教的.但与此同时,您可能会争辩说,与面向对象编程不同,表不是其记录的实例.
由于英语中存在多种不规则现象,我认为我现在正倾向于支持单数.在德语中,由于没有一致的复数形式,情况更糟糕 - 有时你无法判断一个单词是否为复数而没有前面的指定文章(der/die/das).而在中文中,无论如何都没有复数形式.
我总是使用单数,因为这就是我所教的.然而,在最近创建一个新架构时,我很长时间以来第一次主动决定维护这个约定只是因为......它更短.在每个表名的末尾添加's'对我来说似乎没有用,因为在每个表前加上'tbl_'.
我曾经在User表中使用"Dude" - 相同的短字符数,与关键字没有冲突,仍然是对通用人类的引用.如果我不担心可能会看到代码的闷头,我会保持这种方式.
我一直认为这是一个愚蠢的惯例.我使用多个表名.
(我相信该策略背后的理性是它使ORM代码生成器更容易生成对象和集合类,因为从单数名称生成复数名称比反之亦然更容易)
我只使用名词作为拼写相同的表名,无论是单数还是复数:
驼鹿鱼鹿飞机你裤子短裤眼镜剪刀种子后代
准则确实就在那里。这不是“一成不变”的原因，因此您可以选择忽略它们。
我要说，具有复数的表名在逻辑上更直观。表毕竟是实体的集合。除了提到的其他替代方案之外，我通常会在表名上看到前缀...
tblUser
tblThis
那个
tblTheOther
我并不是在建议这样做，我也看到空格在我讨厌的表名中使用了很多。我甚至遇到过带有白痴字符的字段名称？好像说这个领域回答了一个问题。
我只想说明为什么我使用单数名称.
例如,我需要从用户获取所有字段:
-- Select every fields from 'user' table SELECT * FROM user
我需要21岁用户的名字:
-- Select every fields from 'user' table which have 21 years old SELECT * FROM user WHERE age = '21'
当然,复数方式可以通过相同的方式使用,但是对于我的大脑来说,我真的认为这是正确的方法.
表的SQL定义实际上是表的一个潜在行的定义,而不是集合.因此,该定义中使用的名称必须指定行的类型,而不是集合的名称.喜欢复数的人因为在英语陈述中读得好,需要开始更加逻辑地思考并查看实际使用表所涉及的所有逻辑和编程代码.这些注释中提到的几个很好的理由是使用单数表名.这些包括非常好的理由不使用复数表名."读得好"根本不应该是任何理由,特别是因为有些人可能会以不同的方式阅读这个想法.
我以前的任何答案都没有清楚地阐明这一点。使用表时，许多程序员没有正式的定义。我们经常就“记录”或“行”进行直观的交流。但是，除非规范化关系外，通常设计表以使非键属性和键之间的关系构成一个集合理论函数。
函数可以定义为两组之间叉积的子集，其中键集中的每个元素在映射中最多出现一次。因此，从该角度出发产生的术语趋于单一。人们在涉及函数（例如，代数和λ演算）的其他数学和计算理论中看到了相同的单数（或至少是非复数）约定。
京公网安备 11010802040832号 | 京ICP备19059560号-6 