每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
当前回答
我知道这有点晚了,这个问题已经得到了很好的回答,但我想就#3关于列名前缀的问题提出我的看法。
所有列都应该使用一个对定义它们的表唯一的前缀命名。
例如,给定表“customer”和“address”,让我们分别使用前缀“cust”和“addr”。"customer"中会有"cust_id", "cust_name"等。“address”将包含“addr_id”,“addr_cust_id”(FK返回给客户),“addr_street”等。
当我第一次看到这个标准时,我坚决反对它;我讨厌这个主意。我无法忍受所有额外的输入和冗余。现在我已经有了足够的经验,我再也不会回去了。
这样做的结果是数据库模式中的所有列都是唯一的。这有一个主要的好处,它压倒了所有反对它的论点(当然,在我看来):
您可以搜索整个代码库,并可靠地找到涉及特定列的每一行代码。
The benefit from #1 is incredibly huge. I can deprecate a column and know exactly what files need to be updated before the column can safely be removed from the schema. I can change the meaning of a column and know exactly what code needs to be refactored. Or I can simply tell if data from a column is even being used in a particular portion of the system. I can't count the number of times this has turned a potentially huge project into a simple one, nor the amount of hours we've saved in development work.
另一个相对较小的好处是,当你进行自连接时,你只需要使用表别名:
SELECT cust_id, cust_name, addr_street, addr_city, addr_state
FROM customer
INNER JOIN address ON addr_cust_id = cust_id
WHERE cust_name LIKE 'J%';
其他回答
表名一定要保持单数,person而不是people 我也一样 不。我见过一些糟糕的前缀,以至于声明我们处理的是一个表(tbl_)或一个用户存储过程(usp_)。后面跟着数据库名…不要这样做! 是的。我倾向于PascalCase我所有的表名
--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
);
这些是我学到的惯例,但是您应该适应您的开发软管使用的任何东西。
复数。它是实体的集合。 是的。属性是一个实体的单一属性的表示。 是的,前缀表名允许轻松跟踪所有约束索引和表别名的命名。 表和列名用大小写,索引和约束用前缀+ ALL大写。
表名:它应该是单数,因为它是一个表示真实世界对象的单数实体,而不是表示对象的单数实体。
列名:它应该是单数,只有这样它才表示它将持有一个原子值,并将确认归一化理论。然而,如果有n个相同类型的属性,那么它们应该以1,2,…作为后缀。n,等等。
表/列前缀:这是一个巨大的主题,将在后面讨论。
外壳:应该是驼色的
我的朋友Patrick Karcher,我请求你不要写任何可能冒犯别人的东西,就像你写的那样,“此外,外键必须在不同的表中一致命名。如果有人不这样做,殴打他应该是合法的。”我从来没有犯过这样的错误,我的朋友帕特里克,但我写一般。如果他们一起打算为此揍你呢?:)
我的观点是:
1)不,表名应该是单数。
虽然对于简单的选择(select * from Orders)似乎有意义,但对于OO等效(Orders x = new Orders)则没有意义。
数据库中的表实际上是该实体的集合,当你使用set-logic时,它更有意义:
select Orders.*
from Orders inner join Products
on Orders.Key = Products.Key
最后一行,连接的实际逻辑,看起来与复数表名混淆。
我不确定是否总是使用别名(如Matt建议的那样)可以消除这种情况。
2)它们应该是单数,因为它们只拥有一种属性
3)如果列名有歧义(如上所述,它们都有一个名为[Key]的列),表名(或其别名)永远不能很好地区分它们。您希望查询能够快速键入,并且简单-前缀会增加不必要的复杂性。
4)无论你想要什么,我都推荐CapitalCase
我不认为有任何一套绝对的指导方针。
只要你在应用程序或数据库中选择的是一致的,我不认为这真的很重要。
这里有一个链接,提供了一些选择。我正在寻找一个简单的规范,我可以遵循,而不是依赖于一个部分定义的规范。
http://justinsomnia.org/writings/naming_conventions.html