每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
当前回答
命名约定允许开发团队在项目的核心设计可发现性和可维护性。
一个好的命名约定需要时间来发展,但一旦它到位,它就可以让团队使用一种共同的语言向前发展。好的命名约定会随着项目的发展而有机地发展。好的命名约定可以很容易地处理软件生命周期中最长和最重要的阶段(生产中的服务管理)中的变化。
以下是我的回答:
是的,当表名指的是一组交易、证券或交易对手时,表名应该是复数。 是的。 是的。SQL表前缀为tb_,视图前缀为vw_,存储过程前缀为usp_,触发器前缀为tg_,后面加数据库名。 列名应以小写字母用下划线分隔。
命名很难,但在每个组织中都有人可以命名事物,在每个软件团队中都应该有人负责命名标准,并确保像sec_id、sec_value和security_id这样的命名问题在融入项目之前尽早得到解决。
那么,一个好的命名规范和标准的基本原则是什么呢
使用你客户的语言 解域 是描述性的 是一致的 消除歧义,反思和重构 不要使用缩写,除非它们 每个人都清楚 不要使用SQL保留关键字作为 列名
其他回答
不。表应该以它所代表的实体命名。 Person,而不是persons是指记录所代表的人。 同样的事情。列FirstName真的不应该被称为FirstNames。这完全取决于你想用列表示什么。 不。 是的。为清晰起见。如果你需要像“FirstName”这样的列,大小写会让它更容易阅读。
好的。这是我的0.02美元
好吧,既然我们有意见:
我认为表名应该是复数。表是实体的集合(表)。每一行表示一个实体,表表示集合。因此,我将Person实体表称为People(或Persons,随您喜欢)。
对于那些喜欢在查询中看到单一“实体名称”的人来说,这就是我使用表别名的原因:
SELECT person.Name
FROM People person
有点像LINQ的“from person in people select person. name”。
至于2、3和4,我同意@Lars的观点。
Table names should always be singular, because they represent a set of objects. As you say herd to designate a group of sheep, or flock do designate a group of birds. No need for plural. When a table name is composition of two names and naming convention is in plural it becomes hard to know if the plural name should be the first word or second word or both. It’s the logic – Object.instance, not objects.instance. Or TableName.column, not TableNames.column(s). Microsoft SQL is not case sensitive, it’s easier to read table names, if upper case letters are used, to separate table or column names when they are composed of two or more names.
我知道这有点晚了,这个问题已经得到了很好的回答,但我想就#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%';
表名为单数。假设您正在建模某人与其地址之间的关系。 例如,如果您正在读取一个数据模型,您会选择 每个人可以住在0、1或多个地址。”或 每个人可以住在0、1或多个地址。 我认为用复数的称呼比把人写成person更容易。加上集合名词通常与单数名词不同。