学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
指导方针确实如此。这不是“板上钉钉”,这就是为什么你可以选择忽略它们。
我想说,使用多个表名在逻辑上更直观。表毕竟是实体的集合。除了提到的其他选项,我通常在表名上看到前缀。。。
tbl用户tbl此待定tbl其他
我并不是建议这样做,我也看到表名中使用了很多空格,我对此深恶痛绝。我甚至遇到过带有白痴字符的域名,比如?好像说这个字段回答了一个问题。
其他回答
服务器本身的系统表/视图(SYSCAT.tables、dbo.sysindexes、ALL_tables、information_schema.columns等)几乎总是多个。我想为了保持一致,我会追随他们的脚步。
在寻找良好的命名惯例时,我应该如何命名会出现以下困惑:
1) 根据桌子上的东西用户表。它总是复数形式。所以,用户
2) 根据记录的内容用户表中的记录将是单个用户。SO,用户。
现在,主要是用户角色的问题。情况1:根据第一命名约定,users_roles此名称的含义、用户及其角色。
案例2:根据第二种命名约定,user_role这个名字意味着什么,用户和他的角色。
良好的命名约定是提供实体关系的额外概念,尤其是当存储多对多关系时。
在这里,根据场景,我们应该确定为一组信息。
在用户表中,形成的所有集合都是唯一的用户。在“角色”表中,形成的所有集合都是唯一的角色。在用户和角色关系表中,可以用不同的角色组成用户集,这给出了存储1个任意关系的概念。
I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles
我的看法是语义上的,这取决于您如何定义容器。例如,“一袋苹果”或简单的“苹果”或“苹果袋”或“apple”。
例子:“学院”表可以包含0个或多个学院“学院”表可以包含0个或多个学院
a "student" table can contain 0 or more students
a table of "students" can contain 0 or more students.
我的结论是,两者都可以,但你必须定义你(或与之互动的人)在参考表格时将如何处理;“x表”或“xs表”
指导方针确实如此。这不是“板上钉钉”,这就是为什么你可以选择忽略它们。
我想说,使用多个表名在逻辑上更直观。表毕竟是实体的集合。除了提到的其他选项,我通常在表名上看到前缀。。。
tbl用户tbl此待定tbl其他
我并不是建议这样做,我也看到表名中使用了很多空格,我对此深恶痛绝。我甚至遇到过带有白痴字符的域名,比如?好像说这个字段回答了一个问题。
单数的我不相信任何涉及最合乎逻辑的论点——每个人都认为自己的偏好最合乎逻辑。无论你做什么,这都是一团糟,只要选择一个惯例并坚持下去。我们正试图将一种语法和语义高度不规则的语言(正常的口语和书面语言)映射到一种具有非常特定语义的高度规则(SQL)语法。
我的主要论点是,我不认为表格是一个集合,而是一个关系。
因此,AppUser关系告诉哪些实体是AppUsers。
AppUserGroup关系告诉哪些实体是AppUserGroups
AppUser_AppUserGroup关系告诉AppUsers和AppUserGroups是如何关联的。
AppUserGroup_AppUserGroup关系告诉AppUserGroups和AppUserGroup是如何关联的(即组中的组成员)。
换句话说,当我想到实体以及它们是如何关联的时候,我想到的是单数的关系,但当然,当我想起集合或集合中的实体时,集合或集合是复数的。
在我的代码和数据库模式中,我使用单数。在文本描述中,为了提高可读性,我最终使用了复数形式,然后使用字体等将表/关系名称与复数形式区分开来。
我喜欢认为它是混乱的,但有系统的——这样,我想表达的关系总是有一个系统生成的名称,这对我来说非常重要。