Как спроектировать БД?

Question

[lucky4]

Нужно спроектировать сущность пиццы. Она будет иметь атрибуты: id, img, name, ingedients, rating, type, size. Как ее создать и внести картежи, если у пицци много будет ингредиентов и несколько размеров?
Так это представлено в json:

{
      "id": 0,
      "imageUrl": "https://dodopizza.azureedge.net/static/Img/Products/f035c7f46c0844069722f2bb3ee9f113_584x584.jpeg",
      "name": "Пепперони Фреш с перцем",
      "types": [0, 1],
      "sizes": [26, 30, 40],
      "price": 803,
      "category": 0,
      "rating": 4
    },

Answer 1

[PrAw]

А в чем проблема?
Отношение многие-ко-многим
Таблица "Пицца", где код пиццы, размеры, дополнительные данные
Таблица "Заказ", где код заказа, код пиццы
Таблица "Состав", где код заказа, код ингредиента, количество - несколько записей, по количеству ингредиентов
Таблица "Ингредиенты" - код ингредиента, дополнительные данные.
Хотя в простом случае можно тупо хранить JSON в поле таблицы заказа, но дальнейшей обработки уровня "как часто просят добавить ингредиент ...." уже будет сложнее добиться.

Comments

[lucky4]

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

Я знаю, что надо делать отдельно таблицу ингрединтов. НО! Как мне потом передать в "Пиццы" ингредиент1, ингредиент2 и тд?
Надо делать кортежи типу ID-1-Пицца, ингредиент1-помидор, потом ID-2-Пицца, ингредиент2-огурец? А как тогда поступить с другими аттрибутами(тип и размер) сущности Пицца?

[PrAw]

lucky4,

То есть на одну пиццу в таблице заказ одна строка, ссылается на тип пиццы (размер?)
3 ингредиента - 3 строки в таблице ЗаказИнгредиенты, каждая ссылается на номер заказа, на ингредиент. Можно добавить поле для количества или еще чего-то.

Если в заказе несколько пицц, то добавляем еще таблицу ЗаказКлиента, с уник ид, который будет использоваться для связи с таблицей Заказ, ссылаться на клиента.

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

Идиотский вариант - 10 столбцов "ингр1, ингр2, ...., ингр10" в таблице заказа. Неудобство в дальнейшем, но работает. Неудобство - один и тот же ингредиент может оказаться в разных столбцах, так что статистический запрос по картошечке, например, будет включать в себя перебор всех полей (шыза).

В общем случае - читайте как реализовать связь "многие-ко-многим"

Answer 2

[Dimonchik]

ну и нормас, в bJSON и пихай

искать только по JSONb научись