每当我设计数据库时，我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
当前回答
表名一定要保持单数，person而不是people 我也一样 不。我见过一些糟糕的前缀，以至于声明我们处理的是一个表(tbl_)或一个用户存储过程(usp_)。后面跟着数据库名…不要这样做! 是的。我倾向于PascalCase我所有的表名
其他回答
我的观点是:
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
我不认为有任何一套绝对的指导方针。
只要你在应用程序或数据库中选择的是一致的，我不认为这真的很重要。
不。表应该以它所代表的实体命名。 Person，而不是persons是指记录所代表的人。 同样的事情。列FirstName真的不应该被称为FirstNames。这完全取决于你想用列表示什么。 不。 是的。为清晰起见。如果你需要像“FirstName”这样的列，大小写会让它更容易阅读。
好的。这是我的0.02美元
基本数据库命名约定(和样式)(点击这里查看更详细的描述)
表名 选择简短、明确的名字，不要超过一两个单词 容易区分表 方便唯一字段名的命名以及查找和链接表 给表取单数名，而不是复数名(更新:我仍然同意这种惯例的原因，但大多数人真的喜欢复数表名，所以我的立场软化了)…请点击上面的链接
命名约定允许开发团队在项目的核心设计可发现性和可维护性。
一个好的命名约定需要时间来发展，但一旦它到位，它就可以让团队使用一种共同的语言向前发展。好的命名约定会随着项目的发展而有机地发展。好的命名约定可以很容易地处理软件生命周期中最长和最重要的阶段(生产中的服务管理)中的变化。
以下是我的回答:
是的，当表名指的是一组交易、证券或交易对手时，表名应该是复数。 是的。 是的。SQL表前缀为tb_，视图前缀为vw_，存储过程前缀为usp_，触发器前缀为tg_，后面加数据库名。 列名应以小写字母用下划线分隔。
命名很难，但在每个组织中都有人可以命名事物，在每个软件团队中都应该有人负责命名标准，并确保像sec_id、sec_value和security_id这样的命名问题在融入项目之前尽早得到解决。
那么，一个好的命名规范和标准的基本原则是什么呢
使用你客户的语言 解域 是描述性的 是一致的 消除歧义，反思和重构 不要使用缩写，除非它们 每个人都清楚 不要使用SQL保留关键字作为 列名
表名:它应该是单数，因为它是一个表示真实世界对象的单数实体，而不是表示对象的单数实体。
列名:它应该是单数，只有这样它才表示它将持有一个原子值，并将确认归一化理论。然而，如果有n个相同类型的属性，那么它们应该以1,2，…作为后缀。n，等等。
表/列前缀:这是一个巨大的主题，将在后面讨论。
外壳:应该是驼色的
我的朋友Patrick Karcher，我请求你不要写任何可能冒犯别人的东西，就像你写的那样，“此外，外键必须在不同的表中一致命名。如果有人不这样做，殴打他应该是合法的。”我从来没有犯过这样的错误，我的朋友帕特里克，但我写一般。如果他们一起打算为此揍你呢?：）
