Дизайн базы данных: альтернатива композитным клавишам?

Question

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

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

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

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

Что было бы лучшим способом разработать таблицу затрат?

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

Спасибо!

P.S. Если это имеет значение, это интербаза db.

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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