Есть ли стандарты именования primary key, foreign key в БД?

Question

[avada kedavra]

Выполняется join таблицы users с таблицей city. Primary key у обоих таблиц назван id, foreign key в users - city_id. Может есть какой-то стандарт именования PK и FK чтобы не возникало конфликта имен и необходимости использовать алиасы (очень нежелательно)? Например PK - %table%_id, FK - %foreign table%, для моего случая
users: PK - user_id, FK - city
cities: PK - city_id
И чтоб два раза не вставать - стоит ли заводить отдельную таблицу, допустим, для религии, в которой будет от силы 10 значений, или лучше кодировать (1- христианин, 2 - мусульманин и т. д.), а присваивать значение по коду уже в логике приложения? Начиная от скольки значений имеет смысл заводить отдельную таблицу?

Answer 1

[sim3x]

Нет, но если будешь придерживаться в проекте единого стиля именования все будут только рады
stackoverflow.com/questions/199498/foreign-key-nam...

Хотя оракл имеет oracle-base.com/articles/misc/naming-conventions.php
Ну и просто люди любят учить как нужно https://launchbylunch.com/posts/2014/Feb/16/sql-na...

стоит ли заводить отдельную таблицу

зависит от ORM, частоты изменения значений и использования СУБД, как бекенда для обработки (иногда извращаются и пишут в БД код).

Comments

[avada kedavra]

Если код в бд не пишется, ORM самописная, частота изменений... хмм, крайне редко, а может и никогда (если честно не вижу причин когда-нибудь изменять значения вроде 'христианин')?

[sim3x]

avada kedavra: значит просто рядом с моделью положи словарик

Answer 2

[Армянское Радио]

Первое - стандарт вырабатывается в рамках компании или приложения. Вместо алиасов можно использовать формат table.field; например - city.id. Это лучше, чем засовывание названия таблицы в идентификатор.

Второе - всегда все хранить в базе, не смешивать логику и данные. Что будет, если у вас будет база одной версии, а логика - другой версии?