每当我设计一个数据库时，我总是想知道在我的数据库中是否有一种命名项目的最佳方式。 我经常问自己以下问题：
表名是复数？ 列名应该是单数吗？ 我应该在表格还是列上加前缀？ 我应该在命名项目时使用任何情况吗？ 是否有任何建议的指导原则来命名数据库中的项目？
我建议查看微软的SQL Server示例数据库：https：//github.com/Microsoft/sql-server-samples/releases/tag/adventureworks
AdventureWorks示例使用非常清晰且一致的命名约定，该约定使用数据库对象组织的模式名称。
表格的单数名称 列的单数名称 表格前缀的模式名称（例如：SchemeName.TableName） 帕斯卡套管（又名上部骆驼案件）
迟到的答案在这里，但总之：
我的偏好是复数 是 表：*通常*没有前缀是最好的。 专栏：没有。 表和列：PascalCase。 阐述：
（1） 你必须做什么。 每一次你都必须以某种方式做很少的事情，但是有一些。
使用“[singularOfTableName] ID”格式命名主键 。 也就是说，无论您的表名是Customer还是Customers，主键都应该是CustomerID。 此外， 外键必须在不同的表中一致地命名 。 殴打不这样做的人应该是合法的。 我会提出，虽然定义的外键约束通常很重要，但一致的外键命名总是很重要 你的数据库必须有内部约定 。 即使在后面的章节中，您会看到我非常灵活，但在数据库中，命名必须非常一致。 无论您的客户表是客户还是客户，都不如您在同一个数据库中以同样的方式进行。 你可以翻转硬币来确定如何使用下划线，但是你必须继续以相同的方式使用它们。 如果你不这样做，你就是一个自卑心很重的坏人。 （2） 你应该怎么做。
代表不同表上相同类型数据的字段应该命名相同。 不要在一张桌子上有Zip，而在另一张桌子上有ZipCode。 要分隔表或列名称中的单词，请使用PascalCasing。 使用camelCasing本质上不会有问题，但这不是常规，它看起来很有趣。 我会在下一刻解决下划线。 （你可能不会像以前那样使用ALLCAPS，20年前DB2中的OBNOXIOUSTABLE.ANNOYING_COLUMN是可以的，但现在不行。） 不要人为地缩短或缩短单词。 名字长而明确，而不是简短而混乱。 超短名称是从更黑暗，更野蛮的时代延续。 Cus_AddRef。 那究竟是什么？ 保管收件人参考？ 客户额外退款？ 自定义地址推荐？ （3） 你应该考虑什么。
我真的认为你应该有表格的复数名称; 有些人觉得奇怪。 阅读其他地方的观点。 列名应该是单数然而。 即使使用复数表名，表示其他表的组合的表也可能是单数形式。 例如，如果您有促销和物品表，则表示作为促销一部分的物品的表格可以是Promotions_Items，但它也可以合法地成为我认为的Promotion_Items（反映一对多关系）。 始终如一地使用下划线并用于特定目的。 只需使用PascalCasing就可以清楚地了解一般表的名称; 你不需要下划线来分隔单词。 保存下划线（a）表示关联表或（b）前缀表达式，我将在下一个项目符号中解决。 前缀既不好，也不好。 它通常不是最好的。 在你的第一个数据库中，我不会建议使用前缀来表格的一般主题分组。 表格最终不能很容易地适合您的类别，并且实际上可能会使查找表格变得更加困难。 凭借经验，您可以计划并应用一种比伤害更好的前缀方案。 我曾经在一个数据表中工作过，数据表以tbl开头，ctbl配置表，vew视图，proc sp和udf的fn等等。 它一丝不苟，始终如一地适用，所以它的结果没问题。 唯一一次你需要前缀是当你有真正独立的解决方案，由于某种原因驻留在同一个分贝; 为它们加上前缀对于分组表格非常有用。 对于特殊情况，前缀也可以，例如对于要突出的临时表。 很少（如果有的话），你想要前缀列。
好的，因为我们正在认真考虑：
我相信表格名称应该是复数形式。 表是实体的集合（表）。 每一行代表一个实体，表格代表集合。 所以我会打电话给人实体人物（或人物，不管你是谁）。
对于那些喜欢在查询中看到单数“实体名称”的人，这就是我将使用表别名：
SELECT person.Name
FROM People person
有点像LINQ的“从人中挑选person.Name”。
至于2,3和4，我同意@Lars。
链接地址:
http://www.djcxy.com/p/7081.html
上一篇:
Database, Table and Column Naming Conventions?
下一篇:
negotiation to serve webp if the UA requests it
