似乎“_id”后缀在外键名称中很常见。我想知道这背后的原因。
posts(id, user_id, title, text) 与更简单的posts(id, user, title, text) 相比有什么好处？
【问题讨论】：
标签： php mysql database-design naming
遵循这样的命名约定的一大好处：它有助于使错误的 SQL 语句“看起来不正确”。
（Joel Spolsky 的这篇博文“让错误的代码看起来是错误的”并未提及 SQL，但我认为您询问的 SQL 命名约定遵循 Joel 所支持的相同原则。）
http://www.joelonsoftware.com/articles/Wrong.html
规范连接是外键到主键。
当我们遵循使用id作为主键的命名约定，并使用tablename_id（在外键列名的末尾加上_id）时，会导致SQL如下所示：
FROM user
JOIN post
ON post.user_id = user.id
这是一个非常熟悉的模式：代理主键的名称为 id，外键列的名称为 <referencedtable>_id，有时是 <referencedtable>_<role>_id。
查看此 SQL，我们预计 post 表中的 user_id 列是对 user 表中的 id 列的外键引用。当我们虔诚地遵循这种风格命名约定时，不遵循这种模式的 SQL 就会显得“错误”。
举个例子，比较一下：
FROM somedoohickey
JOIN gibberish
ON troubador = minstrel
到：
FROM somedoohickey s
JOIN gibberish g
ON g.id = s.gibberish_id
两者都可能是同样有效的 SQL。但第二种模式向读者传达了更多信息。当我们习惯了命名约定时，前者对我们来说只是看起来“错误”，也就是说，我们怀疑可能有问题。
比较一下：
FROM somedoohickey s
JOIN gibberish g
ON g.id = s.undecipherable_id
看起来有些不对劲。甚至
FROM somedoohickey s
JOIN gibberish g
ON g.id = s.gibberish
再一次，有些东西看起来不太对劲。
【讨论】：
任何命名约定的最大好处是易于学习。后来出现的维护人员将不得不了解数据的含义，其中一些学习将在潜意识中完成，当时甚至没有意识到。使用带有“Id”后缀标记的外键有助于未来的调查人员一眼就知道哪些列是外键，哪些不是。
一些商店使用 CamelCasing 代替下划线来使后缀从词干中突出。
有些商店在主键列名中包含 Id 后缀。这样做的好处是对元数据的查询可以找到外键引用的所有主键。明智地使用命名域也可以做到这一点。
一些商店强调所有或几乎所有外键都在数据定义中声明，包括引用约束以防止孤立的外键。这会产生实质性的后果并有助于调查员。
但要使系统更易于学习并因此更易于访问，最重要的是一致性。如果不一致地遵守约定，则可能会比没有约定更令人困惑。
【讨论】：
这是非常基于意见的，但我会说它更准确地描述了专栏的内容。 1902010 不是用户，它是用户 ID。将其称为 user 与将您的 title 列称为 title_id 一样错误。
【讨论】：
user 之类的列包含与{"id":1902010,"name":"ceejayoz"} 类似的内容。