Создание отношения между тремя таблицами

Question

Есть много способов, которыми я могу думать о том, чтобы взломать это вместе, но я хочу знать, что лучшая практика здесь:

У меня есть три таблицы. Продукты, прейскуранты и цены.

Один товар может принадлежать многим прейскурантам.

Один прейскурант может принадлежать многим продуктам.

Это много-много отношений, и, насколько мне известно, требуется таблица переходов (pricelist_products). Это хорошо работает.

Теперь один продукт в прейскуранте может иметь несколько цен. Продукт только когда-либо получает цену, когда он входит в прейскурант.

О чем я думал, здесь используется идентификатор из таблицы переходов «pricelist_products» в качестве внешнего ключа в таблице цен, но это действительно ... хак?

подозрительный пример:

Продукт 1 - Удочка.

Прейскурант A - Рыбаки.

Прейскурант B - Fishingshop.

Прайс-лист A, продукт 1, цена 1: (Ежемесячные выплаты вариант 1 (без депозита))

Прайс-лист A, продукт 1, цена 2: (Ежемесячные выплаты вариант 2 (с депозитом))

Прайс-лист A, продукт 1, цена 3: (ЕЖЕКВАРТАЛЬНО погашений)

Прайс-лист Б, продукт 1, цена 1: (ЕЖЕКВАРТАЛЬНО погашений)

Answer 1

Если вы бы не использовать где-либо связь между продуктами и прайс-листы, но по ценам, то альтернативный дизайн, как это:

-стол продукты с полями: ID, другие

-стол с полями Прейскурант цен: ID, другие

-стол цены с полями ID (автоинкремент), pRODUCT_ID, pricelist_id, цена

и вы определили бы индекс (не единственный) на пару полей pRODUCT_ID, pricelist_id

Answer 2

Что я здесь думал об использовании идентификатора из таблицы переходов «pricelist_products» в качестве внешнего ключа в таблице цен, но это действительно ... хак?

Возможно, проблема здесь является лишь одним из перспективных. Цель таблицы соединений состоит в том, чтобы однозначно определять каждую комбинацию в пределах вашего отношения «многие ко многим» (изначально: pricelist - product).Это может быть достигнуто в таблице соединений с полями product_id и pricelist_id и без суррогатного ключа id.

Конечно, если вы определили свою таблицу соединений с PRIMARY KEY (product_id, pricelist_id), эта таблица не будет иметь возможности однозначно определять комбинации, если учитывается price. Таким образом, вы добавляете третью таблицу id в таблицу соединений. Похоже, вы рассматривали это поле как необходимый суррогатный ключ при определении отношения между двумя таблицами. Однако, поскольку реальная полезность этого поля относится к третьей таблице, вы можете назвать ее price_id вместо этого, назовите свою таблицу соединений pricelist_product_price и определите первичный ключ для всех трех полей (например). Это более четко демонстрирует цель каждой области, и поэтому на практике она не может быть «хакерской».

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

Отредактировано для добавления: Хорошо, есть еще одно изменение. Я забыл упомянуть, что подпадает под «хороший» дизайн или лучшие практики. На вашей фотографии у вас есть два поля ID в таблице price, где этого будет достаточно. Как указал @Gilbert Le Blanc, вы должны попытаться избежать неоднозначных имен полей, например, иметь несколько полей id, даже если они находятся в разных таблицах. Это поможет вам увидеть полезность ваших полей, определить естественные ключи и устранить избыточность.