Лучшая практика для позиции столбцов Внешнего ключа в таблице
Это могло бы быть глупым вопросом, но здесь идет:
Существует ли общепринятая практика или лучшая практика, которая указывает, в каком порядке должны столбцы внешнего ключа в таблице?
Я для одного как идея PK, являющегося самым первым столбцом в таблице, сопровождаемой всеми внешними ключами и затем столбцами, это относится к той таблице..
Другой способ сделать его имеет PK как самый первый столбец, затем все столбцы поддержки и затем все внешние ключи...
Я предполагаю, что это действительно не имеет значения, но я хотел бы получить стандарт через свою организацию по этому...
6 ответов
Интересная идея, но лично я думаю, что наличие "стандарта в моей организации" для этого принесет больше вреда, чем пользы.
Обучение и лучшие практики - это хорошо, но слепо применяемое правило "считается вредным".
Совершенно неважно, я думаю, что важнее всего то, как вы назовете столбцы. Обеспечение того, чтобы все внешние ключи соответствовали каким-то соглашениям, упростит вашу жизнь при разработке.
например, добавление суффикса _fk ко всем внешним ключам или что-то подобное.
Таким образом, vehicle_id становится vehice_id_fk при использовании в качестве внешнего ключа.
Там, где я работал, я сначала видел PK, затем внешние ключи, а затем данные. Но ДХО правильный; это не имеет значения. Порядок, в котором вы указываете индексы с несколькими столбцами, имеет решающее значение, но не порядок, в котором вы указываете столбцы в таблице. Если вы добавите суффикс к именам столбцов внешнего ключа с помощью _fk, _key или _id или аналогичного соглашения, это сэкономит время вам и вашим преемникам.
Согласен с DRL. Соглашение, основанное на упорядочивании столбцов, было бы трудно поддерживать по мере добавления новых столбцов. Кроме того, большинство клиентов db смогут предоставить вам список столбцов и их обозначения (PK, FK и т.д.).
Порядок столбцов внешнего ключа в таблице не имеет и не должен иметь значения. Лучший стандарт, который я видел (который, естественно, со временем ухудшается):
- Столбцы первичного ключа
- Столбцы NOT NULL, которые имеют «фиксированную» длину и вряд ли изменятся.
- Столбцы NOT NULL, которые могут быть заполнены с помощью update
- Столбцы, допускающие NULL, которые, вероятно, будут заполнены с помощью update
- Столбцы, допускающие значение NULL или нет, которые почти всегда изменяются. (Подумайте о столбце MOD_TIMESTAMP, который используется для оптимистической блокировки без сохранения состояния.)
Целью такой реализации является количество требуемой регистрации при обновлении.
С точки зрения представления, достойный инструмент ERD должен представлять ссылки на внешние ключи как на уровне столбца, так и на уровне «строки».
Кроме того, я бы не стал следовать совету, который видел ранее - например, VEHICLE_ID_FK. Просто поместите VEHICLE_ID в дочернюю таблицу таблицы VEHICLE и двигайтесь дальше. Если вам нужно несколько столбцов VEHICLE_ID, присвойте им соответствующий тип, например COPS_VEHICLE_ID и ROBBERS_VEHICLE_ID.
Я бы посоветовал не иметь такого правила. «Правила для дураков».
Что бы произошло, если бы вы действительно ввели такое правило, и кто-то захотел бы добавить новый ключ? Или добавить новый столбец к существующему ключу? Должны ли они для этого переставить все столбцы? Я не понимаю, что вы от этого выиграете.
В идеале столбцы должны быть названы так, чтобы было понятно, что в них находится. Это непросто, и небольшая дополнительная мысль окупится в долгосрочной перспективе.