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

Question

Я строю систему базы данных и у меня возникают проблемы с дизайном одной из моих таблиц.

В этой системе есть таблица пользователей, таблица объектов, таблица позиций и таблица затрат.

Уникальная запись в таблице затрат определяется пользователем, объектом, товаром и годом. Однако может быть несколько записей одного года, если элемент отличается.

Иерархия состоит из пользователя-> объект-> элемент-> год, нескольких уникальных лет на элемент, нескольких уникальных элементов на объект, нескольких уникальных объектов на пользователя, нескольких уникальных пользователей.

Как лучше всего составить таблицу затрат?

Я подумываю включить userid, objectid и itemid в качестве внешних ключей, а затем использовать составной ключ, состоящий из userid, objecid, itemid и costyear. Я слышал, что составные ключи - это плохой дизайн, но я не уверен, как их структурировать, чтобы избежать использования составного ключа. Как вы можете сказать, мои навыки построения баз данных немного устарели.

Спасибо!

P.S. Если это имеет значение, это межбазная база данных.

Answer 1

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

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

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

Answer 2

Используйте внутренне сгенерированное ключевое поле (называемое суррогатными ключами), что-то вроде CostID, которое пользователи никогда не увидят, но будут уникально идентифицировать каждую запись в таблице Cost (в SqlServer такие поля, как uniqueidentifier или IDENTITY, будут работать)

Answer 3

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

Когда вы объявляете составной первичный ключ, порядок столбцов в вашем объявлении не повлияет на логические последствия объявления. Однако составной индекс, который создает для вас СУБД, также будет иметь столбцы в том же порядке, и порядок столбцов в составном индексе влияет на производительность.

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