Соглашение об именах первичного / внешнего ключа [закрыто]

В нашей группе разработчиков ведутся бурные дебаты по поводу соглашения об именах для первичных и внешних ключей. В нашей группе есть две основные точки зрения:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

или

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Я предпочитаю не дублировать имя таблицы ни в одном из столбцов (поэтому я предпочитаю вариант 1 выше). Концептуально это согласуется со многими рекомендуемыми практиками на других языках, где вы не используете имя объекта в именах его свойств. Я думаю, что присвоение имени внешнему ключу EmployeeID(или Employee_IDможет быть лучше) говорит читателю, что это IDстолбец Employeeтаблицы.

Некоторые другие предпочитают вариант 2, где вы называете первичный ключ с префиксом имени таблицы, чтобы имя столбца было одинаковым во всей базе данных. Я это понимаю, но теперь вы не можете визуально отличить первичный ключ от внешнего.

Кроме того, я считаю излишним иметь имя таблицы в имени столбца, потому что, если вы думаете о таблице как о сущности, а столбец как о свойстве или атрибуте этой сущности, вы думаете об этом как об атрибуте идентификатора Employee, а не EmployeeIDатрибут работника. Я не иду и не спрашиваю своего коллегу, что он PersonAgeили что PersonGenderтакое. Я спрашиваю его, сколько ему лет.

Итак, как я уже сказал, это бурные дебаты, и мы продолжаем и продолжаем об этом. Мне интересно узнать о новых перспективах.

Это не имеет значения. Я никогда не сталкивался с системой, в которой существует реальная разница между выбором 1 и вариантом 2.

Некоторое время назад у Джеффа Этвуда была отличная статья на эту тему. В основном люди яростно спорят и спорят по тем вопросам, в отношении которых нельзя доказать, что они не правы. Или, с другой стороны, те темы, которые можно выиграть только с помощью выносливости в стиле флибустьера, основанной на аргументах последнего человека.

Выберите одно и попросите их сосредоточиться на проблемах, которые действительно влияют на ваш код.

EDIT: если вы хотите повеселиться, попросите их подробно указать, почему их метод лучше для рекурсивных ссылок на таблицы.

Если два столбца имеют одно и то же имя в обеих таблицах (соглашение № 2), вы можете использовать синтаксис USING в SQL, чтобы избежать некоторого набора текста и некоторого шаблонного шума:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

Еще один аргумент в пользу соглашения №2 заключается в том, что так была разработана реляционная модель .

Значимость каждого столбца частично передается путем пометки его именем соответствующего домена.

Я думаю, это зависит от того, как составлено ваше приложение. Если вы используете ORM или разрабатываете свои таблицы для представления объектов, то вариант 1 может быть для вас.

Мне нравится кодировать базу данных как отдельный слой. Я все контролирую, а приложение просто вызывает хранимые процедуры. Приятно иметь наборы результатов с полными именами столбцов, особенно когда много таблиц соединено и возвращается много столбцов. С таким типом приложения мне нравится вариант 2. Мне очень нравится, чтобы имена столбцов совпадали при объединениях. Я работал со старыми системами, где они не совпадали, и это был кошмар,

Ни одно из соглашений не работает во всех случаях, так зачем вообще использовать его? Используй здравый смысл...

например, для таблицы со ссылками на себя, когда существует более одного столбца FK, который ссылается на PK одной и той же таблицы, вы ДОЛЖНЫ нарушить оба «стандарта», поскольку два столбца FK не могут быть названы одинаково ... например , EmployeeTable с EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

Согласен, что выбирать между ними особо нечего. Для меня гораздо более важным аспектом любого стандарта является «стандартная» часть.

Если люди начинают «заниматься своим делом», они должны быть привязаны к своим нижним силам. ПО МОЕМУ МНЕНИЮ :)

Вы учли следующее?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

Соглашение, которое мы используем там, где я работаю, довольно близко к A, за исключением того, что мы называем таблицы во множественном числе (т. Е. «Сотрудники») и используем подчеркивания между именем таблицы и столбцом. Преимущество этого метода в том, что для ссылки на столбец это либо «employee _ id», либо «employee.id», в зависимости от того, как вы хотите получить к нему доступ. Если вам нужно указать, из какой таблицы берется столбец, "employee.employees _ id" определенно избыточен.

Если вы смотрите на код приложения, а не только на запросы к базе данных, некоторые вещи мне кажутся ясными:

1. Определения таблиц обычно напрямую сопоставляются с классом, который описывает один объект, поэтому они должны быть единичными. Чтобы описать коллекцию объекта, я обычно добавляю «Массив» или «Список» или «Коллекция» к имени в единственном числе, поскольку это более четко, чем использование множественного числа, указывает не только на то, что это коллекция, но и на то, что это за коллекция. это. В этом представлении я вижу имя таблицы не как имя коллекции, а как имя типа объекта, коллекцией которого она является. Администратор баз данных, который не пишет код приложения, может упустить этот момент.

2. Данные, с которыми я работаю, часто используют «ID» для неключевых целей идентификации. Чтобы избежать путаницы между ключевыми «ID» и неключевыми «ID», в качестве имени первичного ключа мы используем «Ключ» (что это такое, не так ли?) С префиксом имени таблицы или аббревиатурой имя таблицы. Этот префикс (и я оставляю его только для первичного ключа) делает имя ключа уникальным, что особенно важно, потому что мы используем имена переменных, которые совпадают с именами столбцов базы данных, и у большинства классов есть родительский элемент, идентифицируемый по имени родительский ключ. Это также необходимо, чтобы убедиться, что это не зарезервированное ключевое слово, которым является только «Ключ». Чтобы упростить согласованность имен ключевых переменных и обеспечить программы, которые выполняют естественные соединения, внешние ключи имеют то же имя, которое используется в таблице, в которой они являются первичным ключом. Мне не раз приходилось сталкиваться с программами, которые работают намного лучше, используя естественные объединения. По этому последнему пункту я признаю проблему с таблицами, ссылающимися на себя, которые я использовал. В этом случае я бы сделал исключение из правила именования внешнего ключа. Например, я бы использовал ManagerKey в качестве внешнего ключа в таблице Employee, чтобы указать на другую запись в этой таблице.

Мне нравится соглашение №2 - исследуя эту тему и находя этот вопрос перед тем, как опубликовать свой, я столкнулся с проблемой, когда:

Я выбираю * из таблицы с большим количеством столбцов и присоединяю ее ко второй таблице, которая также имеет большое количество столбцов. Обе таблицы имеют столбец «id» в качестве первичного ключа, а это означает, что я должен специально выбрать каждый столбец (насколько я знаю), чтобы сделать эти два значения уникальными в результате, то есть:

SELECT table1.id AS parent_id, table2.id AS child_id

Хотя использование соглашения № 2 означает, что в результате у меня все еще будут столбцы с тем же именем, теперь я могу указать, какой идентификатор мне нужен (родительский или дочерний), и, как предложил Стивен Хьювиг, это USINGутверждение еще больше упрощает ситуацию.

Я всегда использовал userId в качестве PK для одной таблицы и userId в другой таблице в качестве FK. Я серьезно подумываю об использовании userIdPK и userIdFK в качестве имен, чтобы отличить одно от другого. Это поможет мне быстро идентифицировать PK и FK при просмотре таблиц и, похоже, очистит код при использовании PHP / SQL для доступа к данным, что упростит понимание. Особенно, когда кто-то еще смотрит на мой код.

Я использую соглашение №2. Сейчас я работаю с устаревшей моделью данных, где я не знаю, что стоит в данной таблице. Где вред в многословности?

Как насчет наименования внешнего ключа

role_id

где роль - это роль, которую имеет объект, на который указывает ссылка, по отношению к текущей таблице. Это решает проблему рекурсивной ссылки и нескольких fks на одну и ту же таблицу.

Во многих случаях будет идентично названию таблицы, на которую указывает ссылка. В этом случае он становится идентичным одному из ваших предложений.

В любом случае долго спорить - плохая идея

"Где в" порядке ВНУТРЕННЕГО СОЕДИНЕНИЯ сотрудника НА order.employee_id = employee.id "есть ли необходимость в дополнительной квалификации?".

Нет необходимости в дополнительной квалификации, потому что квалификация, о которой я говорил, уже существует.

«причина, по которой бизнес-пользователь обращается к идентификатору заказа или идентификатору сотрудника, заключается в предоставлении контекста, но на уровне базы данных у вас уже есть контекст, потому что вы ссылаетесь на таблицу».

Молитесь, скажите мне, если столбец назван «ID», то как это «ссылка [sic] на таблицу» выполняется точно, если только не уточняется эта ссылка на столбец ID точно так, как я говорил?