Проектирование базы данных: альтернатива составным ключам?
Я строю систему базы данных и испытываю проблемы с дизайном одной из моих таблиц.
В этой системе есть таблица пользователей, таблица объектов, таблица позиций и таблица затрат.
Уникальная запись в таблице затрат определяется пользователем, объектом, товаром и годом. Однако может быть несколько записей, которые имеют один и тот же год, если элемент отличается.
Иерархия состоит из user->object->item->year, нескольких уникальных лет на элемент, нескольких уникальных элементов на объект, нескольких уникальных объектов на пользователя, нескольких уникальных пользователей.
Как лучше всего составить таблицу затрат?
Я подумываю включить userid, objectid и itemid в качестве внешних ключей, а затем использовать составной ключ, состоящий из userid, objecid, itemid и costyear. Я слышал, что составные ключи - это плохой дизайн, но я не уверен, как их структурировать, чтобы избежать использования составного ключа. Как вы можете сказать, мои навыки построения баз данных немного ржавые.
Спасибо!
PS Если это имеет значение, это Interbase DB.
3 ответа
Чтобы избежать составного ключа, вы просто определяете суррогатный ключ. Это содержит искусственное значение, например, автоматический счетчик.
Вы все еще можете (и должны) определить уникальное ограничение для этих столбцов.
Кстати: не только рекомендуется не использовать составные ключи, но также рекомендуется использовать суррогатные ключи. Во всех ваших таблицах.
Используйте внутренне сгенерированное ключевое поле (называемое суррогатными ключами), что-то вроде CostID, которое пользователи никогда не увидят, но будут уникально идентифицировать каждую запись в таблице Cost (в SqlServer такие поля, как uniqueidentifier или IDENTITY, помогут.)
Попробуйте создать базу данных с помощью составного ключа, используя именно те столбцы, которые вы обрисовали, и посмотрите, что произойдет. Ты будешь приятно удивлен. Убедитесь, что в этих четырех столбцах отсутствуют пропущенные данные, и убедитесь, что никакие две строки не имеют одинаковое значение во всех четырех столбцах, что поможет защитить целостность ваших данных.
Когда вы объявляете составной первичный ключ, порядок столбцов в вашем объявлении не повлияет на логические последствия объявления. Однако составной индекс, который создает для вас СУБД, также будет иметь столбцы в том же порядке, и порядок столбцов в составном индексе влияет на производительность.
Для запросов, которые указывают только один, два или три из этих столбцов, индекс будет бесполезным, если первый столбец в индексе - это столбец, не указанный в запросе. Если вы заранее знаете, как ваши запросы мне нравятся, и какие запросы чаще всего нужно выполнять быстро, это может помочь вам объявить столбцы для первичного ключа в правильном порядке. В редких случаях создание двух или трех дополнительных индексов в один столбец может ускорить выполнение некоторых запросов за счет замедления обновлений.