每当我设计数据库时，我总是想知道是否有最佳的方式在数据库中命名项目。我经常问自己以下问题：

• 表名应该是复数吗？
• 列名称应为单数吗？
• 我应该为表格或者列添加前缀吗？
• 我在命名项目时应该使用大小写吗？

是否有建议的指南来命名数据库中的项目？

解决方案

回答

• 否。表应以其代表的实体命名。无论记录中的哪一位代表，人都是人，而不是人。
• 再说一遍。实际上，FirstName列不应称为FirstNames。这完全取决于我们要用该列表示什么。
• 不。
• 是的。为了清楚起见，请对其进行大小写。如果我们需要具有" FirstName"之类的列，则使用大写将使其更易于阅读。

好的。那是我的0.02美元

回答

好的，因为我们考虑了很多意见：

我认为表名应为复数。表是实体的集合(表)。每行代表一个实体，表代表集合。因此，我将称一个"人"实体"人"表(或者称"人"，无论我们喜欢什么)。

对于那些希望在查询中看到单数的"实体名称"的人，这就是我将表别名用于：

SELECT person.Name
FROM People person

有点像LINQ的"从人中选人"。

至于2、3和4，我同意@Lars。

回答

我认为我们和团队将为每个问题提供最佳答案。拥有命名约定远比命名约定的精确度重要得多。

由于没有正确的答案，因此我们应该花一些时间(但不要太多)并选择自己的约定，这是坚持该约定的重要部分。

当然，这是我们所要询问的关于标准的信息，这很好，但不要着急或者担心我们可能会得到的不同答案的数量：选择一个对我们来说更好的答案。

以防万一，这是我的答案：

• 是的。桌子是一组记录，老师或者演员，所以...是复数形式。
• 是的。
• 我不使用它们。
• 我经常使用的数据库-Firebird-将所有内容都以大写形式保存，所以没关系。无论如何，当我编程时，我会以一种易于阅读的方式(例如releaseYear)来编写名称。

回答

• 否。我已经看到了一些可怕的前缀，甚至可以说是要处理的是表(tbl_)还是用户存储过程(usp_)。然后是数据库名称...不要这样做！
• 是的。我倾向于PascalCase我所有的表名

回答

我对这些的看法是：

1)不，表名应为单数。

尽管对于简单的选择("从订单中选择*")似乎很有意义，但对于面向对象的等效物("订单x =新订单")却没有意义。

数据库中的表实际上是该实体的集合，一旦使用set-logic，它就更有意义了：

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

最后一行，即连接的实际逻辑，看上去与复数的表名混淆了。

我不确定是否总是使用别名(如Matt所建议的那样)可以解决这一问题。

2)它们应为单数，因为它们仅拥有1个财产

3)永远不要，如果列名模棱两可(如上图，它们都具有称为[Key]的列)，则表名(或者其别名)可以很好地区分它们。我们希望查询能够快速键入，而简单的前缀会增加不必要的复杂性。

4)无论我们想要什么，我都建议使用CapitalCase

我认为，在任何这些指导原则上都没有一套绝对的指导原则。

只要我们选择的内容在整个应用程序或者数据库中是一致的，我就认为这并不重要。

回答

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

这些是我所教的惯例，但是我们应该适应我们开发软管使用的任何情况。

• 复数。它是实体的集合。
• 是的。该属性表示实体的奇异属性。
• 是的，前缀表名称允许轻松跟踪所有约束索引和表别名的命名。
• Pascal表和列名称的大小写，前缀和索引和约束的全部大写。

回答

我在一个具有三个DBA的数据库支持团队中工作，我们考虑的选项是：

• 任何命名标准都比没有标准要好。
• 没有"一个真实的"标准，我们都有我们的偏好
• 如果已经有标准，请使用它。不要创建另一个标准或者混淆现有标准。

我们对表使用单数名称。表通常以系统名称(或者其缩写)为前缀。如果系统复杂，这很有用，因为我们可以更改前缀以按逻辑方式将表分组(即reg_customer，reg_booking和regadmin_limits)。

对于字段，我们希望字段名称包含表的前缀/ acryonm(即cust_address1)，并且我们也更喜欢使用标准的后缀集(_id表示PK，_cd表示"代码"，_nm表示"名称" "，_nb代表"数字"，_dt代表"日期")。

Foriegn键字段的名称应与"主键"字段相同。

IE。

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

在开发新项目时，建议我们写出所有首选的实体名称，前缀和首字母缩写词，然后将此文档提供给开发人员。然后，当他们决定创建一个新表时，他们可以引用该文档，而不是"猜测"该表和字段应被调用的内容。

回答

命名约定使开发团队可以在项目的心脏设计可发现性和可维护性。

好的命名约定需要花费一定的时间才能发展，但是一旦落实就可以使团队以通用的语言向前发展。良好的命名约定与项目一起自然发展。良好的命名约定可以轻松应对生产中软件生命周期服务管理的最长且最重要的阶段中的更改。

这是我的答案：

• 是的，当表名称涉及一组交易，证券或者交易对手时，表名称应为复数形式。
• 是的。
• 是的。 SQL表的前缀为tb_，视图的前缀为vw_，存储过程的前缀为usp_，触发器的前缀为tg_，后跟数据库名称。
• 列名应使用小写字母，并用下划线分隔。

命名很困难，但是在每个组织中都有一个可以命名的人，并且在每个软件团队中都应该有人对命名标准负责，并确保诸如sec_id，sec_value和security_id之类的命名问题在进入项目之前就得到解决。 。

那么，良好的命名约定和标准的基本原则是什么？

• 使用客户和解决方案域的语言
• 具有描述性
• 始终如一
• 消除歧义，反映和重构
• 除非所有人都清楚，否则不要使用缩写
• 不要使用SQL保留关键字作为列名

回答

我建议检查Microsoft的SQL Server示例数据库：
https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

AdventureWorks示例使用非常清晰和一致的命名约定，该约定使用模式名称来组织数据库对象。

• 表的单数名称
• 列的单数名称
• 表前缀的架构名称(例如：SchemeName.TableName)
• Pascal机壳(又称上驼壳)

回答

看看ISO 11179-5：命名和识别原则
我们可以在这里获得它：http://metadata-standards.org/11179/#11179-5

我在这里写过一篇有关它的博客：ISO-11179命名约定

回答

在我看来：

• 表名应为复数。
• 列名应为单数。
• 不。
• 对于表名和列名，都可以使用CamelCase(我更喜欢)或者underscore_separated。

但是，就像已经提到的那样，任何约定总比没有约定好。无论我们选择哪种方式，都应记录在案，以便以后的修改遵循相同的约定。

回答

这是一个提供一些选择的链接。我在寻找可以遵循的简单规范，而不必依赖部分定义的规范。

http://justinsomnia.org/writings/naming_conventions.html

回答

我也赞成ISO / IEC 11179样式命名约定，并指出它们是准则而非说明性的。

请参阅Wikipedia上的数据元素名称：

"表是实体的集合，并遵循集合命名准则。理想情况下，使用集合名称：例如，人员。复数也是正确的：Employees。不正确的名称包括：Employee，tblEmployee和EmployeeTable。"

与往常一样，规则也有例外，例如始终只有一行的表可能会更好，例如使用单数名称。配置表。一致性是至关重要的：检查商店是否有约定，如果有，请遵循；否则，请遵循该约定。如果我们不喜欢它，那么可以做一个商业案例来对其进行更改，而不要成为唯一的管理员。

回答

这里的答案很晚，但总之：

• 我的偏好是复数
• 是的
• 表格：通常最好没有前缀。列数：
• 表格和列：PascalCase。

详细说明：

(1)你必须做什么。每次我们必须以某种方式做的事情很少，但也有一些。

• 使用" [singularOfTableName] ID"格式命名主键。也就是说，无论表名是"客户"还是"客户"，主键都应该是"客户ID"。
• 此外，必须在不同的表中一致地命名外键。殴打不这样做的人应该是合法的。我认为虽然定义的外键约束通常很重要，但是一致的外键命名始终很重要
• 数据库必须具有内部约定。即使在以后的部分中，我们会看到我非常灵活，但在数据库中命名必须非常一致。与我们在同一数据库中以相同的方式进行操作相比，将客户的表称为"客户"还是"客户"并不那么重要。我们可以掷硬币来确定如何使用下划线，但是我们必须继续使用下划线。如果我们不这样做，那么我们就是一个自卑的坏人。

(2)我们可能应该做什么。

• 代表不同表上的同类数据的字段应命名为相同的字段。不要在一个表上有邮政编码，而在另一个表上没有ZipCode。
• 要在表名或者列名中分隔单词，请使用PascalCasing。使用camelCasing并不是本质上的问题，但这不是约定，看起来很有趣。我稍后会强调下划线。 (我们可能不像以前那样使用ALLCAPS。OBNOXIOUSTABLE.ANNOYING_COLUMN在20年前在DB2中还可以，但现在不行。)
• 不要人为地缩短或者缩写单词。名字简短明了总比简短而混乱更好。超短名称是对更黑暗，更野蛮的时间的保留。 Cus_AddRef。那到底是什么？托管收件人参考？客户额外退款？自定义地址推荐？

(3)我们应该考虑的问题。

• 我真的认为我们应该为表使用复数名称。有些人认为单数。阅读其他地方的论点。但是，列名应为单数。即使我们使用复数表名，代表其他表组合的表也可能是单数。例如，如果我们具有"促销"和"项目"表，则表示某个项目是促销的一部分的表可以是Promotions_Items，但也可以合法地是我认为的Promotion_Items(反映一对多关系)。
• 为特定目的而始终使用下划线。使用PascalCasing，一般表的名称应该足够清楚；我们不需要使用下划线来分隔单词。保存下划线(a)以表示关联表，或者(b)作为前缀，我将在下一个项目符号中解决。
• 前缀既不是好事也不是坏事。通常不是最好的。在第一个或者两个数据库中，我不建议对表的常规主题分组使用前缀。表格最终不容易符合类别，这实际上会使查找表格更加困难。凭经验，我们可以计划并应用一个弊大于利的前缀方案。我曾经在db中工作过，其中数据表以tbl开头，配置表以ctbl开头，vew的视图，proc的sp和udf的fn以及其他一些文件；它经过精心，始终如一的应用，因此效果还不错。需要前缀的唯一时间是，由于某种原因，我们拥有真正独立的解决方案时，它们位于同一数据库中。给它们加上前缀可以对表进行分组非常有帮助。在特殊情况下也可以使用前缀，例如要突出显示的临时表。
• 我们很少(如果有的话)想给列加上前缀。

回答

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

回答

我们的偏好：

• 表名应该是复数吗？绝不。将其作为集合的参数很有意义，但我们永远不知道表将包含什么(0，1或者许多项目)。多个规则使命名不必要地变得复杂。一栋房子，两栋房子，老鼠与老鼠，人与人，我们甚至都没有看过其他语言。 "更新人员设置属性='值'"作用于表中的每个人员。从人员选择*，其中person.name ='Greg'返回人员行的集合/行。
• 列名称应为单数吗？通常，是的，除非我们要违反规范化规则。
• 我应该为表格或者列添加前缀吗？通常是平台偏好。我们更喜欢为表名加上前缀列。我们不为表加前缀，但为视图(v_)和stored_procedures(sp_或者f_(函数))加前缀。这可以帮助想要尝试更新v_person.age的人，该v_person.age实际上是视图中的计算字段(无论如何都无法更新)。这也是避免关键字冲突的好方法(delivery.from会中断，而delivery_from不会)。它确实使代码更加冗长，但通常有助于提高可读性。 bob = new person()``bob.person_name ='Bob'``bob.person_dob ='1958-12-21'... ...具有很高的可读性和显式性。但是，这可能会失控：customer.customer_customer_type_id`指示customer和customer_type表之间的关系，指示customer_type表(customer_type_id)上的主键，如果在调试查询时看到" customer_customer_type_id"，我们会立即知道它来自的位置(客户表)。或者在customer_type和customer_category之间有M-M关系(某些类型只能用于某些类别)，customer_category_customer_type_id ... ...从长远来看有点(！)。
• 我在命名项目时应该使用大小写吗？是的-小写:)，带下划线。这些都是可读性强且跨平台的。与上面的3一起使用也是有道理的。其中大多数是首选项。 -只要我们保持一致，对任何需要阅读的人来说都是可以预见的。