Отдельные ИЛИ Сгруппированные / Комбинированные элементы для записей в базе данных

Question

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

Как мне разработать базу данных в такой ситуации?

В моем текущем примере у меня есть (простые) пищевые ингредиенты и (комбинированные) пищевые блюда и я хочу, чтобы Либо Один , либо эти Вещи были бы записями в таблице питания / питания.

Таким образом, пользователь может съесть простую еду, такую ​​как Apple ИЛИ сложный продукт, такой как Apple P ie, который состоит из 200 г яблок и 100 г муки и 30 г сахара и c. в какой-то момент времени в еде. Я думаю примерно так:

Ингредиенты | IID | | Имя | | Калории |

Блюда | DID | | Имя | (| Калории | ???)

Данные о еде | DID | | IID | | Сумма |

.

Пользователи | UID | | FirstName | | LastName | et c.

Питание | UID | | DID | | Дата / время | | Сумма |

Я нахожу это действительно раздражающим, поскольку каждый отдельный ингредиент должен иметь две (в основном идентичные) записи для начала: 1 в таблице ингредиентов и 1 в таблице блюд, чтобы их можно было объединить в пару в еде. Я что-то здесь упускаю? Есть ли способ обойти это?

Также я не знаю, должен ли Di sh включать калории в базу данных. Наличие калорий для Di sh в базе данных довольно избыточно, потому что его можно вычислить при создании запроса (суммируя и вычисляя его соответствующие ингредиенты). НО это кажется довольно неэффективным, так как это вычисление должно было бы быть сделано для каждого отдельного запроса di sh (и оно ухудшилось бы, добавляя такие вещи, как Macros / Nutrional Values ​​/ Price, которые я оставил здесь для ясности / простоты) .

Также, если у меня DO есть калории (и другие вещи, относящиеся к еде в целом) для Di sh, я мог бы просто иметь одну таблицу в этом сценарии, например:

Еда | FID | | Имя | | Калорийность | (| Простой [bool] |?)

Данные о продуктах питания | FID | | FID | | Сумма |

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

НО, если я хочу представить Specifi c Di sh -Только данные, тогда я хотел бы сделать некоторые другие таблицы, такие как:

DI SH DATA | FID | | TimetoCook | | Презентация | и др c. (что кажется мне довольно странным / не интуитивным)

.

Итак, вопрос в том, что такое ЛУЧШАЯ общая практика в этом сценарии ?

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

Answer 1

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

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

Итак, ваша первая проблема - это семантика базы данных. Ваш первый подход кажется более естественным; большинство людей легко увидят различие между ингредиентами и блюдами семанти c. Это также единственный вариант, если сущность «ингредиент» имеет другую причину существования, помимо того, что является частью di sh, например, для управления заказами сырья. Если вы выберете go со вторым подходом, вам нужно будет убедиться, что а) он соответствует вашим данным и б) вы очень тщательно выбираете имена таблиц.

Для второго подхода "подходит ваш Данные "семантически, простые блюда должны полностью соответствовать описанию:" блюда, у которых нет лишних dish_data ". Флаг [Simple] также допустим в качестве свойства di sh, хотя реальная потребность в нем может быть намеком на то, что вы не согласны с этим подходом. Но если ингредиенты и блюда частично перекрываются, т. Е. Если у вас есть ингредиенты, которые не могут быть блюдами, или если они имеют разные свойства в целом, то вы определенно не в курсе. Если вам необходимо обеспечить соблюдение бизнес-правил, которые не позволят заказчику заказать порцию «муки»; если у вас возникнут вопросы, например, о том, что поставить под «калории» для «солений» (будет ли это калорий на 100 г для солений в качестве ингредиента или калорий на порцию для соленых огурцов sh); если вы обнаружите, что у вас есть такие поля, как «единица измерения», которые не имеют смысла для блюд, то вы имеете дело с двумя отдельными сущностями (ингредиенты и блюда), а не с одной сущностью (di sh) с двумя подкатегориями (простой и сложный). Если вы собираетесь дублировать только крошечную информацию между двумя таблицами и избавить себя от множества неприятностей и двусмысленности, непременно сделайте это.

Ваша вторая задача - как будут использоваться данные. Попробуйте ответить на такие вопросы, как: Собираетесь ли вы запрашивать калории блюд миллионы раз в секунду? Составляющие - и следовательно калории - блюд останутся такими же навсегда? Потребуется ли когда-либо вашему клиенту или повару спросить, из чего состоит ди sh?

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

Answer 2

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

meal      | calorific value per 100g | glicemic index  
apple     | 12345                    | 34234
apple-pie | 3233                     | 32334

Другой стол, к которому вы бы присоединились, мог бы быть составом еды для определенного c человека.

2020-02-27|Johny Doe | Breakfast |apple  | 300 g
2020-02-27|Johny Doe | Breakfast |sausage| 150 g
2020-02-27|Johny Doe | Breakfast |apple-juice | 500 g

Присоединившись к двум столам, вы узнаете, сколько Джонни Доу ел каллоры и, возможно, что такое глицеми c индекс ...

Тогда ... это is not yet an SQL question but a the question of understanding first the process one would like to describe с SQL.