Денормализовать данные или ключ из нескольких столбцов?

Question

Я пытаюсь принять решение о реализации базы данных SQL Server 2008 малого размера.

Я перевожу выходной текстовый файл базы данных с плоскими файлами из старой системы COBOL в вышеупомянутую базу данных SQL Server. Это база данных по кредитам на покупку автомобиля и недвижимости, которая может быть однозначно идентифицирована по комбинации идентификатора кредитора (семизначный номер), номера банковского счета (15 цифр) и «суффикса счета» (две цифры).

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

1) Определите каждый заем, используя ключ из трех столбцов вышеуказанных значений, или
2) Денормализуйте данные путем реализации столбца «ключ», который представляет собой 24-символьную строку, объединяющую три значения.

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

Составной ключ более элегантен, но я прочитал несколько трактатов, в которых говорится, что это плохо.

Итак, какой вариант, вероятно, будет лучшим выбором, и что более важно, почему?

Answer 1

Я бы использовал сгенерированный автоматически суррогатный ключ и затем поместил бы уникальный индекс в естественный ключ. Таким образом, если естественный ключ изменяется (и, может быть, если какой-то банк был выкуплен другим банком), то его нужно изменить только в одном месте. Самое важное в использовании суррогатного ключа - обеспечить уникальность естественного ключа, если он будет выполнен, и уникальный индекс сделает это.

Answer 2

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

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

Я бы вообще не предлагал реализовать вариант 2.

Answer 3

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