当设计数据库时,我总是不清楚是否有命名我的数据库中的项的最佳方式。往往我问自己以下问题︰

  1. 应表名称为复数形式?
  2. 列名称应为单数?
  3. 应作为前缀表或列?
  4. 应在命名的项目使用任何用例?

是否有任何建议的命名数据库中的项准则?

2008-08-11 10:27:22
问题评论:

为什么您最后选择了所选的答案吗?有很多投票为复数形式的表名,您选择了单数的选票。只是好奇吗?

我认为归结到喜好问题,这问题的最佳答案应该总结的竞争性选择。phasetwenty 的回答下面的链接到多个;很好内联的此处链接。

我认为我们应该命名为表复数和单数的列。

我看到一个表,如"存储"与多个项目,不单一"实体",因此我将它命名为复数形式。当我到对象映射表时,我会命名为单数形式的对象。这是只是我个人的意见。

四处走动的 @Tryinko 使用 ID 执行联接多个表的每个人都是生活的灾难。没有可能得知这微小的优势是 PK 一次次地胜过 re 别名在查询中每个 bloody 可恶 ID 列的令人难以置信的烦恼的方法。如果您需要一种方式来表示表格中的 PK,使其第一列。列的名称表示 FKs 也在我看来另一个牢固邪恶的反模式。

回答:

我建议签出 Microsoft SQL Server 示例数据库︰ http://codeplex.com/SqlServerSamples

该 AdventureWorks 示例使用非常明确和一致的命名约定使用组织的数据库对象的架构名称。

  1. 单数名称表
  2. 单数名称列
  3. 表前缀的架构名称 (例如︰ SchemeName.TableName)
  4. Pascal 大小写格式 (也上部 camel 大小写)

wilsonmar.com/sql_adventureworks.htm是优秀 AdventureWorks 架构分析。

我不会依赖任何标准的 Microsoft-如果您看一下他们的罗斯文数据库,您将看到他们使用复数表、 单数的列名称、 架构前缀表、 表为主键列、 匈牙利语式约束前缀和严重的所有空格加上前缀""多字表名称。另外 SQLServer 的系统表使用复数,使它看上去 AdventureWorks 已在此组中的害群之马。

我认为主要的问题是单数表名称人群似乎认为是实体,而不是复数人群执行表中的行的表。您必须问自己它本来就是。如果只用行的表,则不使用复数命名更合理?您永远不会将命名为单数,代码中的集合,然后为什么会命名表单数?为何不一致?我听到有关如何排序并使用联接,但那些在所有参数中所有看起来是非常 flimsy 参数。如果这一切归结到首选项时,我将与一致性,以复数形式表示。

此外应考虑这一势头将会向哪个方向。看起来复数形式的表名的方向将是特别是因为在 SQL Server 中的所有系统表都都所有复数,和实体框架的默认值是开箱即用复数形式。如果是 Microsoft 的姿态,我想转方向,我们将是 20 年。即使使用 Oracle 的数据库约定说复数形式的表名。只是认为多少 c# 开发人员憎恨"var"关键字,当它被引入,现在是被广泛接受的方法来定义变量。

@Jasmine-我看到您的角度看,虽然我认为无意中向后命名示例表。"TableOfInvoices"应缩短到"发票",这是我更喜欢。您可能实际上意味着"InvoiceTable,"其意义来缩短"发票"。

后期回答此处,但简而言之︰

  1. 我的喜好是复数
  2. 是的
  3. : * 通常 * 无前缀是最好的。︰ 否。
  4. 表和列︰ 采用 Pascal 大小写。

细化︰

(1)您的必须 do. 有很少做的事都必须以某种方式,每一次,但有几个。

  • 您使用格式"[singularOfTableName] ID"的主键的名称。即,表名称是客户 ,主关键字应为客户 id.
  • 此外,在不同表中的外键必须以一致的方式命名它应该是法律上不满足该条件的人打败。我认为,虽然定义外键约束是通常很重要,一致外键命名是总是重要
  • 您的数据库必须具有内部约定尽管在后面的部分您将看到我正在非常灵活数据库命名, 必须非常一致。是否您客户的表称为客户不太重要比您这样做同一个数据库中相同的方式。您可以切换硬币来决定如何使用下划线,但您必须继续使用这些相同的方式如果不这样做,您是应具有低 self-esteem 坏人。

(2)可能应 do.

  • 字段表示相同类型的数据在不同的表具有相同的名称。在另一个表和邮政编码上没有安装 Zip。
  • 若要分隔表或列名称的单词,请使用 PascalCasing。使用 camelcasing 大小写约定不是本质上有问题,但这并不是该公约和看起来有趣。我将在稍后解决下划线。(不能使用 ALLCAPS 同 olden 天一样。OBNOXIOUSTABLE。ANNOYING_COLUMN 可以在 DB2 20 几年前,但不是现在。)
  • 不要 artifically 缩短或缩写词。它是很长而且明显比短和令人混淆的名称中的显示效果会更好。最短名称是从颜色更深、 更 savage 时间供电。Cus_AddRef。地球上那是什么?照管接收者引用?客户其他退款吗?自定义地址引用?

(3)您应该考虑。

  • 我真的认为应具有复数名称表;一些认为单数形式。阅读其他位置的参数。但是应为单数列名称。即使使用复数形式的表名,则表表示组合的其他表可能在单数。例如,如果您有促销活动表,表示要在升级过程中的可能是 Promotions_Items,但它可能也合法是 Promotion_Items 项目表我认为 (反映为一对多关系)。
  • 使用下划线,以一致的方式和针对特定用途。只是一般的表名称应该足够明确,与 PascalCasing;您不需要下划线来分隔文字。保存强调 (a) 为指示相关表或 (b) 作为前缀,这我将在下一个项目符号中简要介绍。
  • 前缀是既不好或坏。通常不是最佳。在您第一个 db 或两个,不建议使用常规确保主题分组的表前缀。不容易,管接头类别表到头来,它实际上会很难查找表使它。经验,您可以计划并应用 prefixing 方案不比伤害更多良好。我从事数据库一旦其中数据表入手tbl,配置ctbl视图、 过程的sp,和 udf 的fn,和其他几种; 具有视图的表认真、 一致地应用了所以它破解好。您需要添加前缀的时,才是有真正独立的解决方案,由于某种原因驻留在相同的数据库;前面可以对表进行分组很有帮助。前缀也是好特殊情况下,如为您想要与众不同的临时表。
  • 极少 (如果有) 您想要作为列的前缀。

"表示相同类型的数据在不同的表上的字段应该具有相同的名称。没有 Zip 一个表和邮政编码在另一台。"是的是的万倍是。您能告诉我们的数据库中不是这样吗?过程可能在十几个不同的方式,非常令人讨厌,可维护的任何引用。我始终一直回想这一规则的任何数据库中对设计的控制,它可以让生活变得更加简单。

我认为只应"ID"的主键。这样一个简单的约定使主键,可预测,并快速识别。我会但是,在前面添加表名称 ("过程") 当其用作其他表中的外键。此约定可以帮助区分主键,而且在同一个表的外键。

四处走动的 @Tryinko 使用 ID 执行联接多个表的每个人都是生活的灾难。没有可能得知这微小的优势是 PK 一次次地胜过 re 别名在查询中每个 bloody 可恶 ID 列的令人难以置信的烦恼的方法。如果您需要一种方式来表示表格中的 PK,使其第一列。列的名称表示 FKs 也在我看来另一个牢固邪恶的反模式。

如果您使用只需"ID"@Triynko,它也无法以编程方式来确定表它属于。使用表名称前缀,可以只是切断主关键字的最后两位数并知道它通过代码所属的表名称。很多时候 IT 和 DBA 用户没有意识到有为编程人员在设计数据库以某些方式编码的优点。

我同意 Triynko 的用户表中的 id 的主键与 customer 表则具有自己作为主键的 id 字段以及过程域,即清楚地向人表的外键。它非常直观的数据库设计策略。变量被命名为使用相同的约定。

好了,因为我们正在权衡使用的意见︰

我相信表名称应该是复数形式。表是实体的集合 (表)。每一行代表一个单一的实体,并表表示集合。因此我把人实体的用户的表 (或人,无论采用您的丰富想象)。

对于那些喜欢以查看单个查询中的"实体名称",这是什么我将使用表的别名︰

SELECT person.Name
FROM People person

有点像 LINQ 的"人中人选择人。名称"。

2、 3 和 4,我同意 @Lars。

@Emtucifor︰ 在英语中,我们不要说"看人,人群中有的所有的人 !"有概念问题是多个被引用的单数形式的单词是意料之中的事情。它是既不正常也不正常。"数据"是卷的超常而通常用来指一种物质,很像"蛋糕"。"您会像 (一张) 蛋糕?"命名表"人",因为它包含多个个体的信息更有意义得多比它命名为"人员"。名为行的"人员"的数据类意义,单数的列的名称一样。

@Emtucifor︰ 所有语言最终都是任意和传统。我已就下述问题的讨论,通常我们引用了一个项集合的项的类型复数为其中。因此每行都有一个人的信息的行的集合作为集合的人应为 refferred。但是,如果您想要把它作为一个人,继续向右。

@Emtucifor︰ 是的 lol。将表命名为"PersonCollection"将等同于它命名为"人"。而在这种收藏命名的只是"人",这没有意义,:)

@Emtucifor︰ 然后我们把它从另一个角度放置在上下文中的命名约定。假设您有表示行和表的对象类。"人员"很明显有意义的类表示一个数据行。如果表已也名为"人员",则可能发生命名冲突或混乱。我只是认为,更有意义的名称对象与准确的 plurality。有关个人数据的行应是人,而有关个人或多个人员的信息的表叫做人、 PersonCollection、 人员等。

@Josh M。好吧,不就可以了。如果你再用我的方式您可以作为"人"的人表的别名,并有选择的人。名称。问题解决了。;-)

我在三个 Dba 数据库支持团队工作,我们考虑的选项︰

  1. 任何命名标准优于没有标准。
  2. 没有"一个 true"标准,我们都有我们的首选项
  3. 如果没有标准已经到位,用它。不要创建另一个标准或弄现有标准。

我们使用单数名称表。表倾向使用的系统 (或其首字母缩写) 的名称作为前缀。这是非常有用的如果象您这样复杂的系统可以更改组合到一起在逻辑表的前缀 (ie。 reg_customer,reg_booking 和 regadmin_limits)。

对于字段,我们会字段名称是包含前缀/acryonm 的表 (即 cust_address1),我们也喜欢使用的一组标准的后缀 (_id 的 PK,"代码",为"名称",为"编号"、"日期"的 _dt _nb _nm _cd)。

Foriegn 键字段的名称应与主键字段相同。

亦即

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

当开发一个新项目,我建议您写出所有首选的实体名称、 前缀和首字母缩写词并向开发人员提供此文档。然后,当他们决定创建一个新表,他们可以参考文档而不是"推测"的表和字段应调用。

尤其是对于数字 3,我们有一组用户,他们全部获得雇用来自同一公司和他们试图强加其旧的命名标准 (且没有使用我们的其余部分) 的任何那样。最令人讨厌。

当然也可以使 SQL 读取;但我认为我可以翻译。cust_nm 应该是客户名称,booking_dt 应为BookingDatereg_customer,当然我也不知道什么,它是。

@Ian。目的是您坚持到命名 convension 您使用,并使其保持一致。我总是知道,任何日期字段是 _dt,任何名称字段为 _nm。reg 是一种,是"注册"系统 (预订、 客户等) 和所有相关的表将具有相同的前缀。但每到自己...

我同意特定标准未有一致的标准一样重要。但有些标准是错误的。DB2 和列的名称如 CSPTCN、 CSPTLN、 CSPTMN、 CSDLN。人们应该了解,长名称已经被发明了,即我们可以承受使事情可读。

在几年中,我添加了我我开发的应用程序中的表的末尾的新列和市场。有时,在列中使用英文名称,有时我使用西班牙语,有时我重新用于其他用途使用的列,而使用它们删除和添加新列与它的适当的描述性名称。我有意做了这才能对我的源代码进行模糊处理,以防其他人试图 hack 或进行反向工程处理我的代码。我能理解它,只有其他人会失望 !.这样一来,他们始终需要依赖我的任何东西 !

  1. 它所代表的实体应以命名不对表。人,没有人是如何将引用到人其中一个记录表示。
  2. 再次,同样的操作。列名字真的不应调用 FirstNames。这完全取决于您想要表示的列。
  3. 否。
  4. 是的。为清楚起见案例它。如果您需要像"名字"列,大小写将使它易于阅读。

    还行。这是我美元 0.02

添加一些清晰度数字 3-前缀会嵌入到列名称的元数据的一种方式。应该不需要执行此操作在任何现代 DB (过多的使用) 匈牙利表示法的理由相同。

'从订单中选择顶部 15' 或者 '从订单中选择顶部 15'?后者是我 (人类) 的首选。

@Ian Boyd︰ 是︰ 选择排名前 100 位 * 从报告 R 内部联接 VisitReport VR R.ReportID = VR。ReportID。这完全取决于您对它的看法如何。如果将柠檬色的图片放在圆筒上,您会知道没有而无需使用两个外侧,以表明它可能是复数的柠檬内,柠檬。当然,您可能它贴上标签的书面文字"柠檬。"但它也只可能是"柠檬"。若要获取名为"柠檬"的资源,转到此处。

添加列名称中使用大写的 0.01 美元并添加另一个 0.01 美元在列名称中使用下划线,以使其更容易区分列名称在最显眼的。总 = 我 0.02 美元捐赠给您 !

"后它所代表的实体应命名表"表是实体的集合。虽然表也是类型的一个实体,它是类型的实体也将添加到其名称毫无意义的"表"。

请输入您的翻译

Database, Table and Column Naming Conventions? [closed]

确认取消