#sql #database-design #recipe
#sql #database-design #рецепт
Вопрос:
Я хочу создать редактор рецептов на основе SQL для пивоварни. У меня есть n рецептов:
- Каждый рецепт является частью категории.
- У каждой категории есть список шагов.
- Шаги могут быть повторно использованы в одной и той же категории несколько раз и в разных порядках.
- Каждый шаг имеет n заданных значений.
- Уставки меняются в зависимости от рецепта.
- Одни и те же шаги, используемые более одного раза в одной и той же категории, могут иметь разные уставки в одном и том же рецепте.
У меня есть 3 рецепта (BeerA, BeerB и BeerC):
- BeerA и BeerB — это лагер (категория), а BeerC — это стаут (категория).
- Лагер состоит из 5 этапов
(начало, ферментация, ожидание, ферментация, созревание). - Все шаги имеют 2 уставки
(время, температура).
Конкретные уставки BeerA могут быть:
- Начало:
[10 секунд, 30 градусов] - Ферментация:
[2 дня, 27 градусов] - Ожидание:
[3 часа, 25 градусов] - Ферментация:
[3 дня, 23 градуса] - Созревание:
[5 дней, 3 степени]
В BeerB те же шаги, тот же порядок, но с разными заданными значениями. В BeerC всего 3 шага. Что может быть примером дизайна таблицы? Я думал:
- Таблица рецептов
(RecipeID, RecipeName, CategoryID). - Таблица категорий
(CategoryID, CategoryName). - Таблица шагов (мне нужна ссылка на категорию и рецепт).
Как я могу справиться с шагами, используя разные уставки? Я считаю, что мне также нужна таблица уставок, но как ее спроектировать?
Комментарии:
1. Сколько существует различных возможных заданных значений? Если этот список невелик, то есть более простой способ сделать это. В противном случае вам придется абстрагировать / сводить отношение рецепт-заданное значение.
2. Для этого конкретного проекта мне понадобится всего 2 уставки для каждого шага, для следующего проекта это будет, вероятно, больше 10-15. Не более того
3. Статья в Википедии » Нормализация базы данных» даст вам общее представление о том, как создавать таблицы базы данных.
4. Все ли лагеры имеют одинаковые пять шагов, только с разной температурой, временем? Все ли стауты имеют одинаковые 3 шага, только с разной температурой, временем?
5. @DamirSudarevic в этом примере да. Количество шагов или позиций в рецепте можно изменить в главном редакторе, но как только светлое пиво определено / сохранено, та же процедура будет использоваться для всех сортов светлого пива, только с разной температурой и временем, которые будут определены в рецепте пива A или B. В дополнение к этому один и тот же шаг в рецепте лагера, используемый дважды (в моем примере ферментации), может иметь разную температуру, время
Ответ №1:
-- Beer category BCT exists.
--
category {BCT}
PK {BCT}
-- Brewing step STP exists
--
step {STP}
PK {STP}
-- Step sequence number ST# for brewing beer
-- of category BCT is step STP.
--
cat_step {BCT, ST#, STP}
PK {BCT, ST#}
FK1 {BCT} REFERENCES category {BCT}
FK2 {STP} REFERENCES step {STP}
-- Note: ST# in [1,2,3 ..]
-- Beer BER is of beer category BCT.
--
beer {BER, BCT}
PK {BER}
SK {BER, BCT}
FK {BCT} REFERENCES category {BCT}
-- Step sequence number ST# of recipe
-- for brewing beer BER of beer category BCT
-- is at temperature TMP deg, for TIM minutes.
--
recipe {BER, BCT, ST#, TIM, TMP}
PK {BER, ST#}
FK1 {BER, BCT} REFERENCES beer {BER, BCT}
FK2 {BCT, ST#} REFERENCES cat_step {BCT, ST#}
Примечание:
All attributes (columns) NOT NULL
PK = Primary Key
AK = Alternate Key (Unique)
SK = Proper Superkey (Unique)
FK = Foreign Key
Using suffix # to save on screen space.
OK for SQL Server and Oracle, for others use _NO.
For example, rename OPT# to OPT_NO.
Ответ №2:
То, что вы описали, является разумной отправной точкой; У меня был бы объект «Beer», позволяющий хранить информацию о пиве, и у меня также было бы какое-то управление версиями (или датами начала / окончания) рецепта — на случай, если он когда-либо изменится.
Итак, что-то вроде этого (просто пример, не предназначенный для окончательной модели):