似乎“_id”后缀在外键名称中很常见。我想知道这背后的原因。
posts(id, user_id, title, text)相对于更简单的posts(id, user, title, text)有什么好处？
答案 0 :(得分：2)
这是非常基于意见的，但我会说它更准确地描述了该列的内容。 1902010不是用户，而是用户ID。将其称为user与调用title列title_id一样错误。
答案 1 :(得分：2)
遵循这样的命名约定的最大好处是：它有助于使SQL语句出错并且出现错误＆＃34;。
（来自Joel Spolsky的博客文章＆＃34;使错误的代码看错了＃34;并没有提到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，我们希望user_id表中的post列是id表中user列的外键引用。当我们虔诚地遵循这种风格命名约定时，那些不遵循该模式的SQL只会看起来错误＆＃34;。
例如，比较：
FROM somedoohickey
JOIN gibberish
ON troubador = minstrel
为：
FROM somedoohickey s
JOIN gibberish g
ON g.id = s.gibberish_id
两者可能同样有效的SQL。但第二种模式向读者传达了更多信息。当我们习惯于命名惯例时，前者只是看起来错了＆＃34;对我们来说，也就是说，我们怀疑某些事情可能不对。
将其与：
进行比较 FROM somedoohickey s
JOIN gibberish g
ON g.id = s.undecipherable_id
有些事情看起来并不正确。甚至
FROM somedoohickey s
JOIN gibberish g
ON g.id = s.gibberish
同样，有些东西看起来并不合适。
答案 2 :(得分：1)
任何命名约定的最大好处是易于学习。稍后出现的维护者将不得不了解数据的含义，并且一些学习将在潜意识中完成，当时甚至没有意识到。将外键标记为＆＃34; Id＆＃34;后缀有助于未来的调查人员一眼就知道哪些列是外键，哪些列不是。
有些商店使用CamelCasing而不是下划线来使后缀从主干中脱颖而出。
某些商店在主键列名称中包含Id后缀。这具有以下优点：对元数据的查询可以定位外键引用的所有主键。明智地使用命名域也可以做同样的事情。
一些商店通过包含引用约束来防止孤立的外键，使得所有或几乎所有外键在数据定义中都被声明为一个点。这既有实质性的后果，也有助于调查人员。
但是，使系统更易于学习并因此更易于访问的最重要的事情是一致性。如果不一致地遵守一项惯例，那么根本没有任何惯例可能会更加令人困惑。