Нужно ли иметь первичный ключ, который генерируется последовательностью, хотя я не могу использовать его для операций с БД

Question

Привет. У меня была родительская таблица с идентификатором и некоторыми другими столбцами, а также дочерняя таблица, в которой много значений на основе этого идентификатора (внешний ключ). Я хотел создать таблицу с первичным ключом, который является последовательностью, и идентификатором этой родительской таблицы в качестве внешнего ключа, но позже я обнаружил, что у меня есть еще один EMPID внешнего ключа, который по комбинации обеспечивает уникальность. Даже для поиска и пакетного обновления я могу просто использовать комбинацию этих двух FK. Так что мне все еще нужно использовать генератор последовательности помните производительность БД или просто отбросьте основной столбец.

Answer 1

Если вы уверены, что вам НИКОГДА не понадобится или вы не захотите ссылаться на этот ключ, сгенерированный последовательностью (и что никакие другие объекты никогда не будут ссылаться на этот идентификатор), тогда будет безопасно удалить его, так как Пока вы можете гарантировать , что ваша комбинация внешних ключей всегда будет обеспечивать уникальную комбинацию.

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

Answer 2

(я бы поставил это в комментарии, но это слишком долго.)

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

1. По мере роста реляционной модели каждая дочерняя таблица должна включать каждый столбец первичного ключа родителя.
2. Первичные ключи, как и все уникальные ограничения, применяются индексами.
3. В некоторых СУБД просто не может быть достаточно столбцов в индексе, чтобы удовлетворить такие конструкции естественных ключей.
4. Аналогичным образом существуют требования к длине данных для ключей индекса.
5. Наконец, изменяемые первичные ключи должны каскадироваться по всей системе.

Короче говоря:

Если ваши значения ключа могут когда-либо измениться

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

или

у вас есть какие-либо данные, зависящие от этой таблицы, через внешние ключи (это довольно легко изменить при возникновении требования)

тогда

Создайте суррогатный ключ в качестве первичного ключа. Здорово, что вы нашли естественный ключ таблицы; на эти столбцы накладывается уникальное ограничение.

Answer 3

Реляционные пуристы скажут вам, что вам вообще не нужен последовательно генерируемый столбец идентификаторов - что первичный ключ в каждой таблице должен представлять собой комбинацию столбцов, которые вместе однозначно идентифицируют каждую строку.(Если существует несколько комбинаций столбцов, которые делают это, выберите один из них в качестве первичного ключа и принудительно установите другие, используя уникальные ограничения.)являются большими или громоздкими, или где число таких столбцов делает сам первичный ключ большим и громоздким.Вот где я отличаюсь от реляционного пуриста и говорю: добавьте суррогатный ключ (это то, что столбец IDENTITY / Sequence ID более правильно называют).Но убедитесь, что другие ключи по-прежнему применяются с использованием ограничений уникальности.

Так что нет никаких причин, по которым вам нужно иметь столбец ID в таблице.Если бы у каждой таблицы была одна таблица, вы бы подумали, что продукты БД предоставят ее вам автоматически.

Answer 4

Я бы сказал, что лучше наложить все ограничения и ограничения на дизайн базы данных. Они полезны, по крайней мере, если вы находитесь в БД Oracle. См. Tom Kyte (слава AskTom). По его словам, эти ссылки / ограничения используются при определении пути выполнения.

Интересно отметить, как важные ограничения для запроса оптимизация. Многие люди думают о ограничения как вещь целостности данных, и это правда - они есть. Но ограничения используются оптимизатором а также при определении оптимального план выполнения. Оптимизатор принимает как входы.

• Запрос на оптимизацию
• Вся доступная статистика объектов базы данных
• Системная статистика, если имеется (скорость ЦП, скорость ввода-вывода для одного блока и т. Д. - показатели физического оборудования)
• Параметры инициализации
• Ограничения

Это может привести к повышению производительности.

Answer 5

Для согласованности мне нравится иметь суррогатный ключ (автоматически сгенерированный идентификатор / первичный ключ последовательности) во всех моих таблицах. Накладные расходы минимальны, и это обеспечивает согласованный интерфейс программиста со структурой базы данных.