Как спроектировать базу данных содержания элементов в продуктах?

Question

[tripcollor]

Есть таблица содержания микроэлементов в пищевых продуктах
(Содержание элемента в 100 г продукта)



Я так понимаю у меня должна быть отдельная таблица с продуктами питания и отдельная таблица с микроэлементами и потом как то их соотносить и заносить содержание каждого вещества в каждом продукте. Или все же у меня должна быть одна таблица с колонками из всех элементов грубо говоря как на картинке? А может вообще сделать поле с типом json?

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

Подскажите каким образом будет лучше хранить данные такого формата?

Comments

[Модератор]

tripcollor дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац).
В противном случае, ваши вопросы будут удаляться по причине тег-спама, а систематические нарушения приведут к блокировке учетной записи.

Answer 1

[Иван Шумов]

Связанные таблицы.
- таблица продуктов
- таблица элементов
- таблица размерностей
- таблица объединения (ссылка на продукт, на элемент, на размерность и значение)

Очень смущают диапазоны, но их можно записывать как от-до

Comments

[tripcollor]

Иван Шумов Спасибо. По сути таблицу размерностей можно занести в таблицу элементов (2 столбца получится название и размерность), почему вы решили их разделить?

[Иван Шумов]

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

[tripcollor]

Иван Шумов, А что можете посоветовать по поводу хранения такой информации сколько граммов весит один продукт (чайная ложка, столовая ложка, чашка или стакан)(для каждого продукта определяется свой набор). Т.е у меня есть базовая единица измерений (для каждого продукта определяется своя) и там уже легко будет все рассчитать. И + к тому же не хотелось бы писать для каждого продукта в разных измерениях свои данные я так подумал проще завести, что то типа convertion_factor. Т.е допустим у нас базовая величина килограмм, и есть унция convertion_factor для нее будет = 0,0283495. А дальше рассчитать не проблема.

Но как это реализовать в базе данных у меня голова вскипает)))

[Иван Шумов]

tripcollor, ну да, надо иметь справочник измерений и коэфициент приведения к единому измерению

Answer 2

[d-stream]

- 1 отдельная таблица с продуктами питания
- 2 отдельная таблица с микроэлементами
потом как то их соотносить -> третья таблица, где фигурируют ссылки на продукты, микроэлементы и количество

такая (классическая) структура всегда позволит получить из базы перечень микроэлементов продукта, перечень продуктов где встречается какой-то микроэлемент и так далее

Answer 3

[sim3x]

Если елементы не меняются часто, то сделать одну таблицу с 20 полями на каждый продукт (те не делать EAV) - null не занимает много места

Привести все значения к Си (те к кг) и приводить их внесистемным уже в интерфейсе

Comments

[Иван Шумов]

И поддерживать это кодом на каждое изменение? Да вы, батенька, извращенец. На тостере нужно завести дизлайки

[sim3x]

Иван Шумов, вы не пользуетесь MVC/MVT with ORM

OMG

[Иван Шумов]

sim3x, все пользуемся, конечно) просто модуль должен быть завершён и расширяем по потребностям. Такие вещи на поддержку нельзя выносить. Ну и главное - нельзя делать проекты Entity first. Database first only

[sim3x]

Иван Шумов,
Ого, и как часто у вас увеличивается Таблица Менделеева?

Ну и главное - нельзя делать проекты Entity first. Database first only

ето какая-то мантра для 3NF?