Выбор лучшего первичного ключа + нумерация системы

Я бы лично сказал, что будь проще и оставайся с автоинкрементным первичным ключом. Если вам нужно что-то более «читабельное» с точки зрения отображения в программе, то, возможно, одна из ваших других идей, но я думаю, что это просто добавление ненужной сложности в поле первичного ключа.

Я также очень сильно в лагере «не используйте первичные ключи как значимые данные». Каждый раз, когда я нарушал эту политику, она заканчивалась слезами. Рано или поздно значимые данные должны измениться, и если это означает, что вам нужно изменить первичный ключ, это может стать болезненным. Первичный ключ, вероятно, будет использоваться в ограничениях внешнего ключа, и вы можете потратить целую вечность, пытаясь разобраться во всем просто для простого изменения данных.

Я всегда использую идентификаторы GUID / UUID для своих первичных ключей в каждой таблице, которую я когда-либо создавал, но это просто личные предпочтительные сериалы или тому подобное, также хорошо.

Не вкладывайте смысл в поля вашего ПК, если ...

• Совершенно невозможно, что значение никогда не изменится и что

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

Перейдите к варианту 1 и отформатируйте значение в приложении, чтобы оно отображалось как вариант два или три при его отображении.

Я думаю, что здесь важно помнить, что каждая таблица в вашей базе данных / дизайне может иметь несколько ключей. Это ключи-кандидаты . См. Статью в Википедии для ключей-кандидатов

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

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

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

• Неизменный / Стабильный - Значения первичного ключа не должны изменяться. В противном случае вы рискуете ввести аномалии обновления
• Not Null - большинство платформ СУБД требуют, чтобы атрибуты первичного ключа не были нулевыми
• Simple - простые типы данных и значения для физического хранения и производительности. Целочисленные значения здесь хорошо работают, и этот тип данных выбирается для большинства суррогатных / автоматических ключей

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

Следуйте политике «Не пользуйтесь».

Некоторые проблемы, с которыми вы можете столкнуться:

Вам необходимо генерировать ключи из более чем одного хоста.

Кто-то захочет зарезервировать смежные номера для совместного использования.

Насколько значимыми будут люди? Войны ведутся из-за этого, и вы уже в первой стычке. «Это уже имеет смысл, и если мы просто добавим еще две цифры, мы сможем ...», то есть вы создаете стиль дизайна, который будет (должен) быть расширяемым.

Если вы объединяете их, вы выполняете типы трансляций, которые могут испортить ваш оптимизатор запросов.

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

Есть обходные пути для всего этого, но это проблема, когда обходные пути распространяются и выходят из-под контроля. И это не займет больше пары, чтобы выйти за рамки "Простого".

Как упоминалось ранее, сохраняйте свои внутренние первичные ключи просто как ключи, какой бы самый оптимальный тип данных не находился на вашей платформе.

Однако вам нужно разрешить аргумент системы нумерации, поскольку это на самом деле является бизнес-требованием, и, возможно, давайте назовем его системой идентификации для актива.

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

    Identifier-type table             Identifier-cross-ref table
      type-id             ------------> type-id              (unique
      type-name                         identifier-string     key)
                                        internal-id

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

Кроме того, вы можете ходить на все собрания, где все спорят друг с другом.

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

Хотя естественные ключи могут иметь большое значение для бизнес-пользователей, если у вас нет соглашения о том, что эти ключи являются священными и их не следует изменять, вы, скорее всего, будете вытягивать волосы, поддерживая базу данных, где " коды продуктов должны быть изменены, чтобы соответствовать новой линейке продуктов, приобретенной компанией ". Вам необходимо защитить RI ваших данных, и наилучшими способами являются целые числа в качестве первичных ключей с автоматическим приращением. Производительность также лучше при индексировании и обходе целых чисел, чем в столбцах char.

Хотя естественные ключи не подходят в качестве первичных ключей, они очень удобны для использования пользователем, и вы можете принудительно вводить уникальные ключи с помощью индекса. Они привносят в данные контекст, который облегчит понимание всеми сторонами. Кроме того, в случае необходимости перезагрузки данных естественные ключи могут помочь убедиться, что ваши поиски все еще действительны.

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

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

Я подозреваю, что вы действительно должны использовать вариант № 3, как многие здесь уже сказали. Суррогатные PK (целые числа или GUID) являются хорошей практикой, даже если имеются адекватные бизнес-ключи. Суррогаты уменьшат головные боли при обслуживании (как вы сами уже отметили).

При этом, возможно, вы захотите рассмотреть вопрос о том, является ли ваша база данных:

1. сфокусированной на ведении данных и обработке транзакций (т. Е. Операциях создания / обновления / удаления)
2. направлены на анализ и отчетность (т.е. запросы)

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

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

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

Надеюсь, вы согласитесь со мной, что каждый элемент дизайна должен иметь единственную цель.

Вопрос в том, что вы думаете о цели PK? Если это идентифицировать уникальную запись в таблице, то суррогатные ключи выигрывают без особых проблем. Это просто и прямо.

Что касается новых столбцов в варианте 3, вам следует проверить, можно ли их рассчитать (лучше всего выполнить вычисления на уровне модели, чтобы их можно было легко изменить, чем если бы расчет выполнялся в СУБД), не слишком много снижение производительности от других элементов. Например, вы можете сохранить номер сегмента и номер дороги в соответствующих таблицах, а затем использовать их для генерации «00000001.1». Это позволит оперативно менять нумерацию активов.

Во-первых, вариант 2 является абсолютно худшим вариантом. Как Индекс, это string, и это делает его медленным. И он генерируется на основе бизнес-правил, которые могут измениться и вызвать довольно большую головную боль.

Лично я всегда использую отдельный столбец первичного ключа; и я всегда использую GUID. Некоторые разработчики предпочитают простой INT, а не GUID по соображениям свободного места на жестком диске. Однако, если возникает ситуация, когда вам необходимо объединить две базы данных, идентификаторы GUID почти никогда не будут конфликтовать (тогда как INT гарантированно будут конфликтовать).

Первичные ключи никогда не должны быть видны пользователю. Делать его читабельным для пользователя не должно быть проблемой. Первичные ключи ДОЛЖНЫ использоваться для связи с внешними ключами. Это их цель. Значение должно быть машиночитаемым и после его создания никогда не должно изменяться.