每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:

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

是否有推荐的指导原则来命名数据库中的项?


当前回答

我的观点是:

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

我不认为有任何一套绝对的指导方针。

只要你在应用程序或数据库中选择的是一致的,我不认为这真的很重要。

其他回答

请参阅ISO 11179-5:命名和识别原则 你可以在这里获得:http://metadata-standards.org/11179/#11179-5

我之前写过一篇博文:ISO-11179命名约定

表名一定要保持单数,person而不是people 我也一样 不。我见过一些糟糕的前缀,以至于声明我们处理的是一个表(tbl_)或一个用户存储过程(usp_)。后面跟着数据库名…不要这样做! 是的。我倾向于PascalCase我所有的表名

表名为单数。假设您正在建模某人与其地址之间的关系。 例如,如果您正在读取一个数据模型,您会选择 每个人可以住在0、1或多个地址。”或 每个人可以住在0、1或多个地址。 我认为用复数的称呼比把人写成person更容易。加上集合名词通常与单数名词不同。

命名约定允许开发团队在项目的核心设计可发现性和可维护性。

一个好的命名约定需要时间来发展,但一旦它到位,它就可以让团队使用一种共同的语言向前发展。好的命名约定会随着项目的发展而有机地发展。好的命名约定可以很容易地处理软件生命周期中最长和最重要的阶段(生产中的服务管理)中的变化。

以下是我的回答:

是的,当表名指的是一组交易、证券或交易对手时,表名应该是复数。 是的。 是的。SQL表前缀为tb_,视图前缀为vw_,存储过程前缀为usp_,触发器前缀为tg_,后面加数据库名。 列名应以小写字母用下划线分隔。

命名很难,但在每个组织中都有人可以命名事物,在每个软件团队中都应该有人负责命名标准,并确保像sec_id、sec_value和security_id这样的命名问题在融入项目之前尽早得到解决。

那么,一个好的命名规范和标准的基本原则是什么呢

使用你客户的语言 解域 是描述性的 是一致的 消除歧义,反思和重构 不要使用缩写,除非它们 每个人都清楚 不要使用SQL保留关键字作为 列名

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