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

Question

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

Учитывая дизайн базы данных ниже, что было бы лучшим вариантом.

Пример 1: Использование автоматических суррогатных ключей.

=================   ==================
Road_Number(PK)     Segment_Number(PK)
=================   ==================
 1                   1

Пример 2: Использование сгенерированного программой PK

=================   ==================
Road_Number(PK)     Segment_Number(PK)
=================   ==================
 "RD00000001WCK"     "00000001.1"

(00000001.1 означает, что это первый сегмент дороги. Это увеличивается каждый раз, когда вы добавляете новый сегмент, например 00000001.2)

Пример 3: Использование битов обоих (добавление нового столбца)

=======================    ==========================
ID(PK) Road_Number(UK)     ID(PK)  Segment_Number(UK)
=======================    ==========================
 1     "RD00000001WCK"       1       "00000001.1"

Немного справочной информации, мы будем использовать Road Number и Segment Number в отчетах и ​​других документах, поэтому они должны быть уникальными .

Мне всегда нравилось держать вещи простыми, поэтому я предпочитаю пример 1, но я читал, что вы не должны раскрывать свои первичные ключи в отчетах / документах. Так что теперь я думаю о том же, что и в примере 3.

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

Как вы думаете, что мы должны делать?

Спасибо.

РЕДАКТИРОВАТЬ: Спасибо всем за отличные ответы, очень помог мне.

Answer 1

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

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

Answer 2

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

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

Answer 3

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