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

Question

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

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

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

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

Каков был бы наилучший способ составления таблицы затрат?

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

Спасибо!

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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