За и против автоинкремента включают “каждую таблицу”
У нас есть довольно долгое обсуждение в нашей компании о том, поместить ли автоинкремент, включают КАЖДУЮ таблицу в нашей базе данных.
Я могу понять помещение того на таблицах, которые имели бы ссылку FK на, но мне отчасти не нравится помещать такой, включает каждую из наших таблиц, даже при том, что ключи никогда не использовались бы.
Помогите с за и против для помещения автоинкремента, включает каждую таблицу кроме занимания дополнительного места и замедления всего немного (у нас есть некоторые таблицы с сотнями миллионов записей).
Спасибо
8 ответов
Я предполагаю, что почти все таблицы будут иметь первичный ключ - и вопрос лишь в том, состоит ли этот ключ из одного или нескольких естественных ключей или одного автоматически увеличивающегося суррогатного ключа. Если вы не используете первичные ключи, вы, как правило, получите много преимуществ от их использования почти во всех таблицах.
Итак, вот несколько плюсов и минусов суррогатных ключей. Во-первых, плюсы:
- Самое главное: они позволяют естественным ключам изменяться. Тривиальный пример, таблица лиц должна иметь первичный ключ person_id, а не last_name, first_name.
- Скорость чтения - очень маленькие индексы сканируются быстрее. Однако это полезно только в том случае, если вы фактически ограничиваете свой запрос суррогатным ключом. Итак, хорошо для справочных таблиц, но не для первичных таблиц.
- Простота - при соответствующем названии упрощает изучение и использование базы данных.
- Емкость - если вы разрабатываете что-то вроде таблицы фактов хранилища данных - суррогатные ключи ваших измерений позволяют вам вести очень узкую таблицу фактов, что приводит к огромному увеличению емкости.
И против:
- Они не предотвращают дублирование естественных ценностей. Таким образом, вам по-прежнему обычно требуется уникальное ограничение (индекс) для логического ключа.
- Запись выступления. С дополнительным индексом вы значительно замедляете вставку, обновление и удаление.
- Простота - для небольших таблиц данных, которые почти никогда не меняются, они не нужны. Например, если вам нужен список стран, вы можете использовать список стран ISO. Он включает значимые сокращения. Это лучше, чем суррогатный ключ, потому что он маленький и полезный.
В общем, суррогатные ключи полезны, просто помните о минусах и не стесняйтесь использовать естественные ключи, когда это необходимо.
В реализацию после логического проектирования добавляются суррогатные автоинкрементирующие первичные ключи с учетом физической, дисковой архитектуры дб движка
То есть они обладают физическими свойствами (узкие, числовые, строго монотонно возрастающие), которые подходят для использования в качестве кластерных ключей, в джоинах и т.д.
Пример: Если вы моделируете свои данные, то "product SKU" - это ваш ключ. После этого добавляется "product ID" (с уникальным ограничением на "product SKU") при написании ваших утверждений "CREATE TABLE", потому что вы знаете SQL Server.
Это основная причина.
Другая причина - мертвый ORM мозга, который не может работать без него...
.Many tables are better with a compound PK, built of two or more FKs (Стоп
WaitFor*()). Эти таблицы соответствуют соотношениям в модели Entity-Relationship (ER). Модель ER полезна для концептуализации схемы и понимания требований, но ее не следует путать с конструкцией базы данных.
Таблицы, в которых представлены объекты из модели ER, должны иметь смайлик PK. Вы используете заменитель PK, когда ни одному из естественных ключей нельзя доверять. Решение о том, можно ли доверять ключу или нет, не является техническим решением. Оно зависит от данных, которые вам будут даны, и от того, что вы должны с ними делать.
Если вы используете суррогатный ключ с автоинкрементом, вы должны убедиться, что дубликаты ссылок на одну и ту же сущность не попали в ваши базы данных. Эти дубликаты будут отображаться в виде двух или более строк с различным PK (потому что он был автоинкрементирован), но в противном случае дубликаты друг друга.
Если вы позволите дубликатам попасть в вашу базу данных, в конечном счете, ваше использование данных будет беспорядочным.
.Самый простой подход заключается в том, чтобы всегда использовать суррогатные ключи, которые либо автоматически вводятся db, либо через orm. И на каждом столе. Это происходит потому, что они являются обычно быстрым методом для соединений, а также они делают изучение базы данных чрезвычайно простым, т.е. ни один из этих ключей не является моим ключом для табличной ерунды, так как все они используют один и тот же тип ключа. Да, они могут быть медленнее, но на самом деле самая важная часть дизайна - это то, что не сломается со временем. Это доказано для суррогатных ключей. Помните, обслуживание системы происходит гораздо дольше, чем разработка. План для системы, которую можно обслуживать. Кроме того, при нынешнем аппаратном обеспечении потенциальная потеря производительности действительно ничтожна
.] Наличие автоинкрементирования первичных ключей может в будущем упростить переключение слоев ORM и не будет стоить дорого (при условии, что вы сохраните ваши логические уникальные ключи)[
].Я не фанат автоинкремента первичных ключей на каждом столе. Идеи, которые дают вам быстрые соединения и быстрые вставки рядов, на самом деле не соответствуют действительности. Моя компания называет этот мясной рулет мыслями после истории о женщине, которая всегда отрезала концы от своего мясного рулета только потому, что это всегда делала ее мать. Ее мать делала это только потому, что сковорода была слишком короткой - традиция продолжает существовать, несмотря на то, что причины этого больше не существует.
Когда у стола для вождения в шарнире есть ключ для автоматического вживления, часто не следует вживлять в шарнир, потому что он должен иметь FK к столу для вождения. Это тот же тип столбца, но не автоинкремент. Вы можете использовать FK в качестве PK или части составной PK.
Добавление автоинкремента к таблице с естественно уникальным ключом не всегда ускорит процесс - как это возможно? Вы добавляете больше работы, сохраняя дополнительный индекс. Если вы никогда не используете клавишу автоинкремента, это совершенно бесполезная работа.
Очень трудно предсказать производительность оптимизатора - и невозможно предсказать будущую производительность. На некоторых базах данных сжатые или кластерные индексы снизят стоимость естественно уникальных PK. На некоторых параллельных базах данных ключи автоинкремента согласовываются между узлами, что увеличивает стоимость автоинкремента. Вы можете узнать это только с помощью профилирования, и это действительно отстойно, когда приходится менять политику компании только для того, чтобы изменить то, как вы создаете таблицу.
Для этих таблиц нужны первичные ключи. Вы просто еще этого не знаете.
Если вы используете такие маленькие ключи для кластеризованных индексов, это дает весьма значительные преимущества.
Например:
Вставки всегда будут в конце страниц.
Некластеризованные индексы (которым нужна ссылка на ключ (и) CIX) не будут иметь длинных адресов строк, которые нужно учитывать.
И еще ... Материалы Кимберли Трипп - лучший ресурс для этого. Погуглите ее ...
Также - если у вас нет ничего другого, обеспечивающего уникальность, у вас есть крючок в каждую строку, которого у вас не было бы иначе. Вы все равно должны помещать уникальные индексы в поля, которые должны быть уникальными, и использовать FK для соответствующих полей.
Но ... учтите накладные расходы на создание таких вещей на существующих таблицах. Это могло быть довольно страшно. Вы можете помещать уникальные индексы в таблицы без необходимости создавать дополнительные поля. Затем эти уникальные индексы можно использовать для FK.