Правильный способ моделировать многие отношения

Question

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

Опция

B вариант

Разница между опцией A и B заключается в способе моделирования таблицы контрактов, в опции A * PK контракта составляется для всех атрибутов, но в опции B PK контракта является только атрибутом id_contract, но контракт имеет два внешних ключа, которые не могут быть нулевыми.

Моя цель в этом проекте - разрешить несколько контрактов между пользователями и поставщиками. Вышеуказанное может быть достигнуто с помощью опции или B , но, если я думаю о функциональных зависимостях, Мне нужно Id_user , Id_Provider и числовая последовательность для идентификации контракта . Проблема в том, что если числовая последовательность автоинкрементируема, она становится суррогатным ключом. Оставляя в стороне всю теорию проектирования баз данных, но если это не саморазвитие, оно становится неотъемлемой частью идентичности сущности ( Id_user , Id_Provider и последовательность чисел ).

Мой вопрос ориентирован на то, чтобы узнать, каковы возможные последствия выбора для модели A или B , думая о хорошем дизайне базы данных.

Большое спасибо!

Answer 1

Этот набор индексов

PRIMARY KEY(contract_id)
INDEX(user_id, provider_id, contract_id),
INDEX(provider_id, user_id, contract_id)

Обеспечивает:

• Остальное, что нужно AUTO_INCREMENT, а именно contract_id, чтобы быть первым столбцом в некотором индексе.
• Эффективный способ получить доступ от пользователя ко всем его поставщикам и наоборот (в виде таблицы «многие ко многим»).

Это также будет работать:

PRIMARY KEY(user_id, provider_id, contract_id),
INDEX(provider_id, user_id, contract_id)
INDEX(contract_id)

Примечания:

• Не применяется UNIQUEness из contract_id, но это не должно быть проблемой, если вы используете AUTO_INCREMENT обычным способом (никогда INSERTing явное значение).
• Предоставляет ссылки, начинающиеся с каждого столбца.

Я не знаю, как правильно нарисовать модель. В какой-то момент схема должна быть реализована, и , которая становится источником истины о том, как работает схема.

При реализации InnoDB любая тройка индексов становится 3 BTrees, каждый из которых содержит все столбцы, но расположены по-разному. То есть SELECTs должен найти либо тройной идентичный по производительности. INSERTs вставит в «конец» BTree для contract_id и вставит в различных местах для двух других BTree. Опять же, нет различий в производительности.

Подробнее о таблицах "многие ко многим" здесь .

Answer 2

Поскольку в любом случае у вас есть уникальный суррогатный ключ id_Contract, нет необходимости включать другие поля в первичный ключ Contract: достаточно одного первичного ключа. Опция «B» также облегчает понимание ваших намерений программистами, изучающими дизайн вашей базы данных.

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