MySQL命名约定,字段名应该包括表名吗?

我同意你的看法。我唯一想把表名或表名的缩写放在主键和外键上,或者如果“自然”名称是关键字的话。

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

我通常使用'id'作为主键字段名,但在这种情况下,我认为user\u id和post\u id也完全可以。请注意,发布日期被称为“发布日期”,因为“日期”是一个关键字。

至少这是我的惯例。您的里程可能会有所不同。

我认为没有理由包含表名,这是多余的。在查询中,您可以将字段称为<表名>&书信电报;字段名>无论如何(例如“user.id”)。

原因是在跨多个表编写联接时可能会造成混淆。

这是个人的喜好,真的,但这就是背后的原因(我总是这样做)。

无论你选择什么方法,都要确保它在项目中是一致的。

就我个人而言,我不会为主表中的字段名添加表名,但当在另一个表中将其用作外部字段时,我会在其前面加上源表名。e、 g.users表上的id字段将被称为id,但在comments表上,如果评论链接到发布它们的用户,则它将被称为user_id。

这是我从CakePHP的命名方案中得到的,我认为它非常简洁。

在列名前面加上表名是保证列名唯一的一种方法,这使得连接更容易。

但这是一种令人厌烦的做法,尤其是当我们有很长的表名时。在适当的时候使用别名通常比较容易。此外,当我们自我加入时,它也没有帮助。

作为一名数据建模师,我发现很难始终保持一致。对于ID列,理论上我更喜欢只使用 ID 但我通常会发现我有一些列叫做 USER_ID , ORDER_ID 等

在某些情况下,跨多个表使用公共列名会带来积极的好处。例如,当逻辑超级类型/子类型关系仅作为子表呈现时,在所有子类型表上保留超级类型的列(例如。 ITEM_STATUS )而不是为每个子类型重命名它( ORDER_ITEM_STATUS , INVOICE_ITEM_STATUS 等)。当它们是具有一组公共值的枚举时,尤其如此。

新的线索 斯卢领土 SL_地区管理者

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

人力资源部候选人 人力资源部面试时间表

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

事实上,这种命名是有原因的,特别是当涉及到字段时,您可能会加入。至少在MySQL中,您可以使用 USING 关键字而不是 ON 然后 users u JOIN posts p ON p.user_id = u.id 变成 users u JOIN posts p USING(user_id) 哪个更干净。

关于其他类型的字段,您可以在选择 * SELECT * 在性能和维护的基础上是不鼓励的,所以我认为前缀这样的字段与表名一个坏的实践,虽然它可能不同于应用到应用。

如果字段名在所有表中都是唯一的-请使用表名作为前缀。如果字段名可能在其他表中重复,请将其命名为唯一。

我找到了字段名,比如“img、address、phone、year”,因为不同的表可能包含不同的图像、地址、电话号码和年份。

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

利益 :-

1) 易读

2) 在连接查询中轻松区分。我们可以尽量减少在查询中使用别名。

用户表:用户id(主键)

post表格:post_id(PK)用户_id(FK) 这里的用户表PK和post表FK是相同的

根据 documentation ,

这样我们就可以 利益 属于 自然连接和使用连接

自然连接和使用的连接(包括外部连接变体)是 根据SQL:2003标准处理。目标是保持一致 MySQL关于自然连接和连接的语法和语义 参加根据SQL:2003使用。但是,这些更改在join中 处理可能会导致某些联接的不同输出列。 此外,有些查询在旧版本中似乎工作正常 (5.0.12之前)必须重写以符合本标准。

这些变化已经发生 五 主要方面:

1) MySQL确定自然或使用join操作的结果列(以及整个FROM子句的结果)的方式。

2) 展开SELECT*并选择tbl_name.*进入所选列的列表。

3) 在自然联接或使用联接中解析列名。

5) 在联接条件下解析列名称。。。在…上

示例:-

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