Преимущества наличия _id & quot; суффикс в именах внешних ключей
Похоже, суффикс «_id» довольно часто встречается в именах внешних ключей. Интересно о причинах этого.
Каковы преимущества posts(id, user_id, title, text) более простой posts(id, user, title, text)?
Решение
Это основано на мнениях, но я бы сказал, что это более точно описывает содержание колонки. 1902010 это не пользователь, это идентификатор пользователя. Называя это user будет так же неправильно, как называть ваш title колонка title_id,
Другие решения
Большая выгода от следования такому соглашению об именах: оно помогает сделать неправильные операторы SQL «неправильными».
(В этом посте Джоэла Спольски «Создание неправильного кода выглядеть неправильно» SQL не упоминается, но я думаю, что соглашение об именовании SQL, о котором вы спрашивали, следует тем же принципам, которые поддерживает Джоэл.)
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, который не следует этому шаблону, выглядит просто «неправильно».
В качестве примера сравните:
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 в имени столбца первичного ключа. Это имеет то преимущество, что запрос к метаданным может найти все первичные ключи, на которые ссылаются внешние ключи. То же самое можно сделать путем разумного использования именованных доменов.
Некоторые магазины утверждают, что все или почти все внешние ключи объявляются как таковые в определениях данных, включая ограничение ссылки, чтобы предотвратить потерянные внешние ключи. Это имеет существенные последствия, а также помогает следователю.
Но самое важное в том, чтобы сделать систему более обучаемой и, следовательно, более доступной, консистенция. Если соглашение не всегда соблюдается, это может быть более запутанным, чем соглашение вообще.