Плюсы и минусы автоинкрементных ключей на " каждом столе"
в нашей компании довольно долго обсуждается вопрос о том, следует ли класть ключ автоинкремента на каждую таблицу в нашей базе данных.
Я могу понять, поставив один на таблицы, которые будут иметь ссылку FK, но мне не нравится ставить такие ключи на каждый из наших столов, хотя ключи никогда не будут использоваться.
пожалуйста помогите с плюсами и минусами для класть ключи autoincrement на каждую таблицу отдельно от принимать экстренный космос и замедлять все немного (у нас есть несколько таблиц с сотнями миллионов записей).
спасибо
9 ответов
Я предполагаю, что почти все таблицы будут иметь первичный ключ - и это просто вопрос о том, состоит ли этот ключ из одного или нескольких естественных ключей или одного автоматически увеличивающегося суррогатного ключа. Если вы не используете первичные ключи, вы обычно получаете много преимуществ от их использования почти во всех таблицах.
Итак, вот некоторые плюсы и минусы суррогатные ключи. Во-первых, плюсы:
- самое главное: они позволяют естественным ключам меняться. Тривиальный например, таблица persons должна иметь первичный ключ person_id, а не last_name, first_name.
- read performance-очень маленькие индексы быстрее сканируются. Однако, это только полезно если вы фактически ограничиваете свой запрос суррогатным ключом. Итак, хорошо для таблиц поиска, не так хорошо для первичных таблиц.
- простота - если названо соответствующим образом, это делает базу данных легко учиться и использовать.
- емкость-если вы конструируете что - то вроде таблицы фактов хранилища данных - суррогатные ключи на ваших измерениях позволяют вам держать очень узкую таблицу фактов-что приводит к огромным улучшениям емкости.
и минусы:
- они не предотвращают дубликаты естественных значений. Таким образом, вы все равно обычно хотите уникальное ограничение (индекс) на логическом ключе.
- скорость записи. С дополнительным индексом вы собираетесь замедлить вставки, обновления и удаления, что значительно больше.
- простота - для небольших таблиц данных, которые почти никогда не меняются, они не нужны. Например, если вам нужен список стран, вы можете использовать список стран ISO. Он включает значимые сокращения. Это лучше, чем суррогатный ключ, потому что он маленький и полезный.
В общем, суррогатные ключи полезны, просто имейте в виду минусы и не стесняйтесь использовать естественные ключи, когда это необходимо.
Если вы используете такие маленькие ключи для кластеризованных индексов, то есть довольно значительные преимущества.
Как:
вставки всегда будут идти в конце страницы.
некластеризованные индексы(которым нужна ссылка на ключ (ы) CIX) не будут иметь длинных адресов строк для рассмотрения.
и многое другое... Вещи Кимберли Трипп-лучший ресурс для этого. Погугли ее...
также - если у вас нет ничего, гарантируя уникальность, у вас есть подключайтесь к каждому ряду, которого у вас не было бы в противном случае. Вы все равно должны поместить уникальные индексы в поля, которые должны быть уникальными, и использовать FKs в соответствующие поля.
но... пожалуйста, рассмотрите накладные расходы на создание таких вещей на существующих таблицах. Это может быть довольно страшно. Вы можете поместить уникальные индексы в таблицы без необходимости создания дополнительных полей. Эти уникальные индексы затем могут использоваться для FKs.
Я не фанат автоинкрементных первичных ключей для каждой таблицы. Идеи, которые они дают вам быстрые соединения и быстрые вставки строк, на самом деле не верны. Моя компания называет это мясным рулетом, думая после истории о женщине, которая всегда отрезала концы от своего мясного рулета только потому, что ее мать всегда это делала. Ее мать сделала это только потому, что сковородка была слишком короткой-традиция продолжается, хотя причины больше не существует.
когда управляя таблица в соединении имеет ключ автоматического приращения, присоединенная таблица часто не должна, потому что она должна иметь FK к таблице вождения. Это тот же тип столбца, но не автоинкремент. Вы можете использовать FK как PK или часть составного PK.
добавление ключа автоматического приращения к таблице с естественным уникальным ключом не всегда ускорит процесс-как это может быть? Вы добавляете больше работы, поддерживая дополнительный индекс. Если вы никогда не используете Ключ auto-increment, это будет полностью потрачено впустую усилие.
очень трудно предсказать производительность оптимизатора-и невозможно предсказать будущую производительность. В некоторых базах данных сжатые или кластеризованные индексы уменьшат затраты на естественно уникальные PKs. В некоторых параллельных базах данных ключи автоматического приращения согласовываются между узлами, что увеличивает стоимость автоматического приращения. Вы можете узнать только по профилированию, и это действительно отстой, чтобы изменить политику компании просто чтобы изменить то, как вы создаете таблица.
наличие автоинкрементных первичных ключей может облегчить вам переключение слоев ORM в будущем и не стоит дорого (при условии, что вы сохраните свои логические уникальные ключи).
вы добавляете суррогатные первичные ключи автоматического приращения как часть реализации после логического проектирования, чтобы уважать физическую архитектуру на диске ядра БД.
то есть они имеют физические свойства (узкие, числовые, строго монотонно возрастающие), которые подходят для использования в качестве кластеризованных ключей, в соединениях и т. д.
пример: Если вы моделируете свои данные, то" продукт SKU " является вашим ключом. "идентификатор продукта" добавляется впоследствии (с уникальным ограничением на "SKU продукта"), когда написание инструкций "создать таблицу", потому что вы знаете SQL Server.
Это основная причина.
другая причина-мозг мертвого Орма, который не может работать без него...
многие таблицы лучше с составным PK, состоящим из двух или более FKs. Эти таблицы соответствуют отношениям в модели Entity-Relationship (ER). Модель ER полезна для концептуализации схемы и понимания требований, но ее не следует путать с дизайном базы данных.
таблицы, представляющие сущности из модели ER, должны иметь smiple PK. Вы используете суррогатный ПК, когда ни одному из естественных ключей нельзя доверять. Решение о можно ли доверять ключу или нет, не является техническим решением. Это зависит от данных, которые вам будут предоставлены, и от того, что вы должны с ними сделать.
Если вы используете суррогатный ключ это несколькими, вы теперь должны убедиться, что повторяющиеся ссылки на одну и ту же сущность не появятся в вашей базе данных. Эти дубликаты будут отображаться как два или более рядов с ярко выраженной ПК (потому что он был несколькими), а иначе дублируют друг друга.
Если вы допускаете дубликаты в свою базу данных, в конечном итоге ваше использование данных будет беспорядочным.
самый простой подход-всегда использовать суррогатные ключи, которые либо автоматически увеличиваются БД, либо через orm. И на каждом столе. Это связано с тем, что они являются обычно голодаемым методом для соединений, а также они делают изучение базы данных чрезвычайно простым, т. е. ни один из них не является моим ключом для таблицы, поскольку все они используют один и тот же ключ. Да, они могут быть медленнее, но на самом деле самая важная часть дизайна-это то, что не сломается со временем. Это доказано для суррогатных ключей. Помните, что обслуживание системы происходит намного дольше, чем разработка. Планируйте систему, которую можно поддерживать. Кроме того, с текущим оборудованием потенциальная потеря производительности действительно незначительна.
рассмотрим следующий пример:
запись удаляется в одной таблице, которая имеет отношение к другой таблице. Соответствующую запись во второй таблице не может быть удалена для проведения аудита. Эта запись становится потерянной из первой таблицы. Если новая запись вставлена в первую таблицу и используется последовательный первичный ключ, эта запись теперь связана с сиротой. Очевидно, это плохо. При использовании автоматически увеличенного PK идентификатор, который никогда не использовался раньше, всегда гарантированный. Это означает, что сироты остаются сиротами, и это правильно.
Я бы никогда не использовал естественные ключи в качестве ПК. Числовое PK, как и автоматическое приращение, является идеальным выбором большую часть времени, потому что его можно эффективно индексировать. Автоматические инкременты гарантированно уникальны, даже при удалении записей, создавая доверительные отношения данных.