Две таблицы к одной таблице как отношение

Question

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

Мои объекты:

• Транспортные средства -> 1: 1 -> Цены
• Велосипеды -> 1: 1 -> Цены

Вариант A:

Создание 2 таблиц

СТОЛ АВТОМОБИЛЕЙ

+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid    |
| brand          | varchar |
| model          | varchar |
| attribute1     | varchar |
| price          | float   |
| discount float |         |
| locale varchar |         |
+----------------+---------+

ТАБЛИЦА ВЕЛОСИПЕДОВ

+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid    |
| vendor         | varchar |
| attribute1     | varchar |
| attribute2     | varchar |
| attribute3     | varchar |
| price          | float   |
| discount float |         |
| locale varchar |         |
+----------------+---------+

Опция B

Создание 3 таблиц

СТОЛ АВТОМОБИЛЕЙ

+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid    |
| brand          | varchar |
| model          | varchar |
| attribute1     | varchar |
+----------------+---------+

СТОЛ ДЛЯ ВЕЛОСИПЕДОВ

+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid    |
| vendor         | varchar |
| attribute1     | varchar |
| attribute2     | varchar |
| attribute3     | varchar |
+----------------+---------+

СТОЛ С ЦЕНАМИ

+----------------+-------+
|      NAME      | TYPE  |
+----------------+-------+
| vehicle_id     | FK    |
| bike_id        | FK    |
| price          | float |
| discount float |       |
| locale varchar |       |
+----------------+-------+

Опция C

Создание 4 таблиц

СТОЛ АВТОМОБИЛЕЙ

+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid    |
| brand          | varchar |
| model          | varchar |
| attribute1     | varchar |
+----------------+---------+

VEHICLES_PRICES TABLE

+----------------+-------+
|      NAME      | TYPE  |
+----------------+-------+
| vehicle_id     | FK    |
| price          | float |
| discount float |       |
| locale varchar |       |
+----------------+-------+

BIKES TABLE

+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid    |
| vendor         | varchar |
| attribute1     | varchar |
| attribute2     | varchar |
| attribute3     | varchar |
+----------------+---------+

BIKE_PRICES TABLE

+----------------+-------+
|      NAME      | TYPE  |
+----------------+-------+
| bike_id        | FK    |
| price          | float |
| discount float |       |
| locale varchar |       |
+----------------+-------+

ПРИМЕЧАНИЕ: я действительно упрощаютаблицы транспортных средств и велосипедов (я не могу объединить их в одну таблицу, например, «продукт»)

Какой у нас будет лучший дизайн для моделей performance и точка зрения?

Answer 1

Если вы можете разделить диапазон идентификаторов на две части (например, менее 50000000 для велосипедов и более 50000000 для автомобилей, перейдите к варианту B. Это позволяет избежать создания неиспользуемых пустых столбцов.
В противном случае опцияC обеспечивает большую гибкость при изменениях, поскольку в будущем данные, необходимые для велосипедов и автомобилей, изменятся по-разному.
Вы также можете сохранить историю цен, добавив дополнительные столбцы / даты DateTime в таблицу / таблицы цен.

Answer 2

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

Обратите внимание, что здесь у вас могут быть транспортные средства или велосипеды, у которых нет цены.

Альтернатива состоит в том, чтобы инвертировать отношение внешнего ключа и иметь три таблицы, подобные этой:

PRODUCTS TABLE
+----------------+---------+
|      NAME      | TYPE    |
+----------------+---------+
| product_id     | uuid    |
| price          | float   |
| discount       | float   |
| locale         | varchar |
+----------------+---------+

VEHICLES TABLE
+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid,FK |
| brand          | varchar |
| model          | varchar |
| attribute1     | varchar |
+----------------+---------+

BIKES TABLE
+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid,FK |
| vendor         | varchar |
| attribute1     | varchar |
| attribute2     | varchar |
| attribute3     | varchar |
+----------------+---------+

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

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

---

Поскольку вы спрашивали о точке зрения модели, решение в этом отношении состояло бы в использовании составного типа для ваших цен . Цена - это не сущность (со своей собственной идентичностью), это просто ценность, которую используют велосипеды и транспортные средства. Здесь у нас будет только две таблицы:

PRICE _TYPE_
+----------------+---------+
|      NAME      | TYPE    |
+----------------+---------+
| value          | float   |
| discount       | float   |
| locale         | varchar |
+----------------+---------+

VEHICLES TABLE
+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid,FK |
| brand          | varchar |
| model          | varchar |
| attribute1     | varchar |
| price          | price   |
+----------------+---------+

BIKES TABLE
+----------------+---------+
|      NAME      |  TYPE   |
+----------------+---------+
| Id             | uuid,FK |
| vendor         | varchar |
| attribute1     | varchar |
| attribute2     | varchar |
| attribute3     | varchar |
| price          | price   |
+----------------+---------+

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

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

Answer 3

Я бы выбрал вариант B, поскольку вы не можете объединить оба. Таким образом, вы можете иметь несколько цен и / или вести учет изменений цен в будущем.