Первичный ключ / [закрытое] соглашение о присвоении имен внешнего ключа

Если два столбца имеют одно и то же имя в обеих таблицах (соглашение № 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, ...

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

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

role_id

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

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

В любом случае длинные споры - плохая идея

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

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

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

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

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

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

Соглашение, которое мы используем там, где я работаю, довольно близко к 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 означает, что в результате у меня все еще будут столбцы с тем же именем, теперь я могу указать , который id мне нужен (родительский или дочерний), и, как предложил Стивен Хьювиг, USING , что еще больше упрощает ситуацию.