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

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

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

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

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

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

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

Спасибо!

PS Если это имеет значение, это Interbase DB.

3 ответа

Решение

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

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

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

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

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

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

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

Другие вопросы по тегам