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

Question

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

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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