MySQL的命名约定，字段名称是否应该包含表名？

一位朋友告诉我，我应该在同一张表的字段名称中包含表名，我想知道为什么？它应该是这样吗？例子：MySQL的命名约定，字段名称是否应该包含表名？

(Table) Users 
(Fields) user_id, username, password, last_login_time

我看到了前缀“用户_”是没有意义的，因为我知道它已经给用户。但我也想收到你的来信。注意：我使用php，mysql进行编程。

来源

2009-08-23 Omar Al-Ithawi

参见：http://stackoverflow.com/questions/529863/do-you-prefer-verbose-naming-when-it-comes-to-database-columns/ 529962＃529962 – 2009-08-23 10:52:07

我正在使用Doctrine-Project（一个ORM框架），它使用像这样：一个（用户）一对一（图片）：用户[编号，名称，年龄，picture_id]，图片[编号，文件名，档案] – 2009-10-26 14:01:06

我同意你的意见。我试图将表名称或其缩写形式放在主键和外键上，或者“自然”名称是关键字。

Users: id or user_id, username, password, last_login_time 
Post: id or post_id, user_id, post_date, content

我一般用的“身份证”作为主键字段的名字，但在这种情况下，我觉得USER_ID和POST_ID是完全OK了。需要注意的是，发布日期被称为“POST_DATE”，因为‘日期’是一个关键词。

至少这是我的习惯。你的情况可能会有所不同。

来源

2009-08-23 10:51:14 cletus

在主键和外键上使用'user_id'而不是'id'的一个优点是可以使NATURAL连接变得轻而易举。 – 2010-04-13 03:10:06

随着像“身份证”和“名”一般的领域，这是很好的把表名。

原因是写在多个表的连接时，它可能会造成混淆。

这是个人喜好，真的，但这是它背后的原因（我总是这样做）。

无论您选择什么方法，都要确保它在项目中一致。

来源

2009-08-23 10:50:14

谢谢，我会保持一致。 – 2009-08-23 11:06:21

我看不出有任何理由，包括表名，这是多余的。在查询，你可以参考字段<表名>。<字段名>反正（例如“user.id”）。

来源

2009-08-23 10:51:23

@Omar Dolaimy：你的“真正的新”与这个答案无关。考虑删除您的评论。 – 2009-08-23 11:14:38

添加前缀表名的列名是保证唯一的列名的方式，这使得连接更容易。

但这是一种令人厌烦的做法，尤其是当我们有长表名时。适当时使用别名通常更容易。此外，当我们自我加入时，这并没有帮助。

作为一个数据建模师，我确实很难始终保持一致。随着ID列理论上我喜欢刚才ID但我通常会发现我有表与ORDER_ID称为USER_ID列，等

有场景中也可以是积极有益的跨多个表使用一个共同的列名。例如，当逻辑超类型/子类型关系已经被渲染为子表格时，保留所有子类型表（例如ITEM_STATUS）上的超类型列是有用的，而不是为每个子类重命名型（ORDER_ITEM_STATUS,INVOICE_ITEM_STATUS等）。当他们具有共同的价值观时，这尤其如此。

来源

2009-08-23 10:55:38 APC

我个人不会为主表中的字段名称添加表名，但在另一个表中使用它作为外部字段时，我会以源表的名称作为前缀。例如users表中的id字段将被称为id，但在评论表上它的评论链接到发布他们的用户，它将是user_id。

这是我从CakePHP的命名方案中选择出来的，我认为它非常整齐。

来源

2009-08-23 11:02:14 partoa

这很常见（我遵循这种做法）。有趣的是，这也是对列名称中的表名争论 - 或者至少不兼容，因为命名方案一开始就会变得混乱。 – lilbyrdie 2010-10-25 19:43:41

例如，你的数据库具有存储着销售和人力资源的部门，你能说出与销售部门所有的表信息表如下所示：

SL_NewLeads SL_Territories SL_TerritoriesManagers

你可以将您所有与人力资源部门相关的表格命名如下：

HR_Candidates HR_PremierInstitutes HR_InterviewSchedules

这种命名约定可以确保，当您按字母顺序列出所有表格时，所有相关的表格都会分组在一起。但是，如果您的数据库只处理一个逻辑表组，则不需要使用此命名约定。

请注意，有时您最终会将表格垂直分区为两个或更多表格，尽管这些分区实际上代表了相同的实体。在这种情况下，将最能识别分区的单词附加到实体名称

来源

2009-08-24 17:12:54

谢谢！这很有用。 – Nirmal 2011-12-22 14:05:15

听起来像结论是：如果字段名称在表中是唯一的 - 带表名的前缀。如果字段名称可能在其他表中重复，则将其命名为唯一。

由于不同的表格可能包含不同的图像，地址，电话号码和年限，我发现了诸如“img，地址，电话，年份”等字段名称。

来源

2010-12-06 22:04:36 huisjames

实际上，这种命名是有原因的，特别是当涉及到领域时，您可能会加入。至少在MySQL中，您可以使用USING关键字代替ON，然后users u JOIN posts p ON p.user_id = u.id变为users u JOIN posts p USING(user_id)，这是更清洁的IMO。

关于其他类型的字段，当选择*时，您可能会受益，因为您不必指定所需字段的列表并确保哪个字段来自哪个表。但一般来说，使用SELECT *不鼓励在性能和功能的基础上，所以我认为在表名的前面加上这样的字段是不好的做法，虽然它可能因应用而异。

来源

2011-07-20 08:45:20 Fluffy

同意，只要你的唯一用例是手写的SQL。 SQL包装器和/或ORM解决方案将具有与相关表fkey作为bar.fooID的foo.id。我将一个手工编码的数据库（chock full o'clean JOIN .. USING ..）迁移到ScalaQuery。如果需要下拉到手动SQL，则语句现在将以SELECT baz FROM foo f JOIN bar b ON f.id = b.fooID的形式出现。当然不是那么干净，但将MySQL和Jedis与SQ之类的功能SQL包装器一起运行意味着强大的类型化查询，而不需要像Hibernate这样的完整ORM的开销。快速和有趣，上TypeSafe火车;-) – virtualeyes 2012-01-15 18:46:06

其实，经过进一步的思考，这个反应得到了我的+1。你可以吃你的蛋糕，也可以吃。创建特定于域的pkeys＆fkeys a la userID，orderID。这允许语义上有意义的字段选择（例如，将alias.fooID与alias.id作为fooID）以及在需要下拉到手动sql时进行自然连接。然后，在包装器/ ORM层处，只需使用domain.id约定，因为无论如何您都在处理对象（即，写入foo.fooID时没有意义，只是说foo.id） – virtualeyes 2012-01-15 19:16:08

我们应该定义带有表名前缀的主键。

我们应该使用use_id来代替id和post_id而不是id。

优势： -

1）易读的

2）容易地区分在连接查询。我们可以最小化查询中别名的使用。

用户表：USER_ID（PK）

交表：POST_ID（PK）的user_id（FK）这里用户表PK和后表FK是相同

作为每documentation，

3）这样我们可以得到的好处的NATURAL JOIN和加入使用

自然连接，并使用，包括外连接加入变种，是根据SQL处理：2003标准。目标是将MySQL的语法和语义与NATURAL JOIN和 JOIN ... USING按照SQL：2003进行对齐。但是，加入处理中的这些更改可能会导致某些连接的不同输出列。此外，一些查询在旧版本（5.0.12之前）中似乎可以正常工作，必须重新编写符合标准的查询。

这些变化主要方面：

1）的MySQL确定自然科学的结果列或使用连接操作（并因此整个FROM子句的结果）的方式。

2）将SELECT *和SELECT tbl_name。*扩展为选定列的列表。

3）解析NATURAL或USING连接中的列名称。

4）转换NATURAL或USING加入JOIN ... ON。

5）在JOIN ... ON的ON条件下解析列名。

例子： -

SELECT * FROM user NATURAL LEFT JOIN post; 
SELECT * FROM user NATURAL JOIN post; 
SELECT * FROM user JOIN post USING (user_id);

来源

2016-06-14 10:16:56

MySQL的命名约定，字段名称是否应该包含表名？

回答

相关问题