La conception d'une base de données de recettes qui doit inclure des ingrédients ainsi que des sous-recettes

Je suis en train de concevoir une recette de base de données qui doit être très souple, comme il va être de communiquer directement avec nos arrière de la maison, système d'inventaire. C'est ce que j'ai jusqu'à présent en ce qui concerne les tables:

Recette: cette table contient la recette date: le nom, les étapes nécessaires pour cuisiner, etc.
Ingrédients/Inventaire: c'est notre arrière de la maison de l'inventaire, ce qui permettra de disposer de l'information sur chacun des produits qui seront utilisés dans nos recettes.
Recette de la Ligne de l'Élément: C'est la complexité de la table, je veux être en mesure de lien à l'un des ingrédients ainsi que la quantité nécessaire pour la recette, mais j'ai aussi besoin d'être en mesure d'inclure directement des recettes à partir de la recette de la table (comme la sauce marinara que nous faisons en interne), et c'est pourquoi j'ai du mal à déterminer la meilleure voie à la conception de cette table.

En gros, la recette élément de ligne de la table doit être en mesure de lien vers les ingrédients de la table ou de la recette de la table en fonction de l'élément de ligne est nécessaire, et je veux savoir quel serait le moyen le plus efficace de gérer cela.

Je vous remercie beaucoup d'avance!

Je ne vois pas pourquoi cette question a été fermé et certainement pas pour la "non constructive". La question est claire et précise. Le vote pour la rouvrir.
Je suis d'accord. C'est parfaitement valide de la base de données de la modélisation question. Le vote aussi pour la réouverture.
Branko Dimitrijevic; Sonne comme une question raisonnable à moi aussi.

OriginalL'auteur VinceL | 2012-12-14

database-design mysql

7

Ressemble vous avez besoin d'un modèle de base de données similaire à ceci:

Ce modèle possède les propriétés suivantes:
- Essentiellement, chaque recette est une série d'étapes.
- Chaque étape a son ordre par rapport à d'autres étapes de la même recette (STEP_NO), une unité (de masse, de volume, de temps...), une quantité de cette unité, etc.
- Une étape particulière soit connecté à un ingrédient (quand INGREDIENT_ID est non-NUL) ou pour une autre recette (quand SUBRECIPE_ID est non NULL).¹
- Autre que cela, l'ÉTAPE est assez standard table de jonction de mise en œuvre de plusieurs-à-plusieurs relations, ce qui signifie que le même ingrédient peut être utilisé dans plusieurs recettes (ou même plusieurs étapes, de la même recette) et aussi une recette peut être un "sous-recette" de plusieurs autres recettes.
- Il s'agit essentiellement d'un graphe orienté. Le modèle de données elle-même ne pourra pas empêcher les cycles - ils doivent être évités chez le client au niveau du code et peut-être détecté par des déclencheurs.
¹ Si MySQL pris en charge la VÉRIFICATION des contraintes (ce qui ne pas), vous pouvez vous assurer que l'un (mais pas les deux) d'entre eux est non NULLE, comme ceci:
```
CHECK (
    (INGREDIENT_ID IS NULL AND SUBRECIPE_ID IS NOT NULL)
    OR (INGREDIENT_ID IS NOT NULL AND SUBRECIPE_ID IS NULL)
)
```
Comme il est, vous aurez besoin d'un déclencheur pour que.

Complément agréable ! merci

OriginalL'auteur Branko Dimitrijevic
3

Ingredients et Recipes sont à la fois possible RecipeItems:
```
CREATE TABLE RecipeItems (
  ItemID       SERIAL,
  Type         ENUM('Ingredient', 'Recipe'),
  Name         VARCHAR(255) NOT NULL,
  Quantity     FLOAT NOT NULL,
  INDEX (ItemID, Type)
);

CREATE TABLE Ingredients (
  IngredientID BIGINT UNSIGNED NOT NULL,
  Type         ENUM('Ingredient'),
  CostPrice    DECIMAL(6,2),
  PRIMARY KEY (IngredientID),
  FOREIGN KEY (IngredientID, Type) REFERENCES RecipeItems (ItemID, Type)
);

CREATE TABLE Recipes (
  RecipeID     BIGINT UNSIGNED NOT NULL,
  Type         ENUM('Recipe'),
  SellPrice    DECIMAL(6,2),
  Date         DATE,
  Instructions TEXT,
  PRIMARY KEY (RecipeID),
  FOREIGN KEY (RecipeID, Type) REFERENCES RecipeItems (ItemID, Type)
);
```
Puis RecipeLineItems:
```
CREATE TABLE RecipeLineItems (
  RecipeID     BIGINT UNSIGNED NOT NULL,
  ItemID       BIGINT UNSIGNED NOT NULL,
  Quantity     FLOAT NOT NULL,
  PRIMARY KEY (RecipeID, ItemID),
  FOREIGN KEY (RecipeID) REFERENCES Recipes     (RecipeID),
  FOREIGN KEY (ItemID)   REFERENCES RecipeItems (ItemID)
);
```
Avec cette approche, je vous recommande d'activer le strict mode SQL (ou d'autre des valeurs non valides seront acceptées dans la ENUM tapé colonnes avec la chaîne vide '' spécial la valeur de l'erreur): cela pourrait briser la destinée de l'intégrité référentielle du modèle ci-dessus. Une alternative (mais un peu plus fastidieux) approche serait d'appliquer l'intégrité référentielle manuellement à l'aide de déclencheurs.

Si seulement MySQL pris en charge CHECK contraintes, hein?

Salut eggyal, je vais être honnête avec vous, je n'ai jamais utilisé de clé étrangère dans la manière que vous l'utilisez sur les Recettes et les Ingrédients tables de faire un lien vers la RecipeItems table, plus particulièrement, la présente ligne: FOREIGN KEY (IngredientID, Type) REFERENCES RecipeItems (ItemID, Type) j'ai l'habitude de les mettre en œuvre de manière similaire à la façon dont vous le mettre en place sur le RecipeLineItems table. Donc ma question est, sera un Ingrédient encore être réutilisable pour d'autres recettes à l'aide de cette installation? Merci beaucoup pour votre réponse!
Tous les FOREIGN KEY n'est contraindre autorisée d'enregistrements à ceux où la liste locale des colonnes correspondent à ceux de la table référencée. Dans ce cas, les enregistrements dans la Ingredients tableau doit correspondre à RecipeItems sur le ID et le Type (mais depuis Ingredients.Type est limitée à la valeur 'Ingredient', il assure ainsi qu'une Ingredient ne peut pas être un Recipe; l'inverse est aussi vrai de la Recipes tableau). Depuis RecipeLineItems.ItemID références RecipeItems.ItemID, mais sans aucune contrainte sur RecipeItems.Type, elle peut faire référence à la fois Ingredients et Recipes.
Bon, je crois que j'ai une bonne compréhension de maintenant, et je pense que c'est une très bonne solution. J'en ai une autre question, quel est le but d'avoir le champ de la quantité à la fois sur les RecipeItems table et le RecipeLineItems table? Je peux voir pourquoi il est nécessaire sur le RecipeLineItems table, mais je suis pas sûr de ce que son utilisation serait sur le RecipeItems table. Merci encore pour vos éclaircissements!
Comment on sait quelle quantité de sauce marinara est produite par sa recette, ou la quantité de sauce de soja vient dans une bouteille?
Ok, je comprends, j'ai été à l'origine être de mettre le champ de la quantité réelle des ingrédients et de la recette des tables, mais il n'a plus de sens, de le stocker dans une table. Merci encore, c'est certainement beaucoup mieux que les solutions que j'avais mis au point jusqu'à présent!

OriginalL'auteur eggyal

Ce script va vous créer une base de données qui vous permet de gérer les recettes, les ingrédients, la zone de composition (ingredients_recipes) et également des unités pour vous de l'inventaire et de la composition. Il vous permet également de gérer votre inventaire de l'histoire.

Voici la requête pour obtenir votre recette, les ingrédients, la quantité nécessaire et le stock que vous avez actuellement :

SELECT recipes.id, recipes.name AS recipeName, ingredients.name AS ingredientNeeded, CONCAT(ingredients_recipes.Qty,' ',neededUnities.name) AS neededQuantity, CONCAT(inventories.qty,' ',inventoryUnities.name) AS availableQuantity FROM recipes 

LEFT JOIN ingredients_recipes ON recipes.id=ingredients_recipes.recipe_id 
LEFT JOIN ingredients ON ingredients_recipes.ingredient_id = ingredients.id 
LEFT JOIN inventories ON ingredients.id=inventories.ingredient_id 
LEFT JOIN unities AS inventoryUnities ON inventories.unity_id=inventoryUnities.id
LEFT JOIN unities AS neededUnities ON ingredients_recipes.unity_id=neededUnities.id

WHERE inventories.`update` = (SELECT MAX(`update`) FROM inventories AS inv WHERE inv.ingredient_id = inventories.ingredient_id);

la base de données :

-- --------------------------------------------------------
-- Host:                         127.0.0.1
-- Server version:               5.5.16 - MySQL Community Server (GPL)
-- Server OS:                    Win32
-- HeidiSQL version:             7.0.0.4053
-- Date/time:                    2012-12-14 16:33:22
-- --------------------------------------------------------
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET FOREIGN_KEY_CHECKS=0 */;
-- Dumping database structure for database
DROP DATABASE IF EXISTS `database`;
CREATE DATABASE IF NOT EXISTS `database` /*!40100 DEFAULT CHARACTER SET latin1 */;
USE `database`;
-- Dumping structure for table database.ingredients
DROP TABLE IF EXISTS `ingredients`;
CREATE TABLE IF NOT EXISTS `ingredients` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`name` varchar(250) NOT NULL,
`unity_id` int(11) NOT NULL COMMENT 'for the default unity',
`Created` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `Unity_id` (`unity_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Dumping data for table database.ingredients: ~0 rows (approximately)
DELETE FROM `ingredients`;
/*!40000 ALTER TABLE `ingredients` DISABLE KEYS */;
/*!40000 ALTER TABLE `ingredients` ENABLE KEYS */;
-- Dumping structure for table database.ingredients_recipes
DROP TABLE IF EXISTS `ingredients_recipes`;
CREATE TABLE IF NOT EXISTS `ingredients_recipes` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`ingredient_id` int(10) NOT NULL,
`recipe_id` int(10) NOT NULL,
`Qty` float NOT NULL,
`Unity_id` int(10) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `ingredient_id_recipe_id` (`ingredient_id`,`recipe_id`),
KEY `Unity_id` (`Unity_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Dumping data for table database.ingredients_recipes: ~0 rows (approximately)
DELETE FROM `ingredients_recipes`;
/*!40000 ALTER TABLE `ingredients_recipes` DISABLE KEYS */;
/*!40000 ALTER TABLE `ingredients_recipes` ENABLE KEYS */;
-- Dumping structure for table database.inventories
DROP TABLE IF EXISTS `inventories`;
CREATE TABLE IF NOT EXISTS `inventories` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`ingredient_id` int(10) NOT NULL COMMENT 'ingredient',
`qty` int(10) NOT NULL COMMENT 'quantity',
`unity_id` int(11) NOT NULL COMMENT 'unity for the ingredient',
`update` datetime NOT NULL COMMENT 'date of the inventory update',
UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Dumping data for table database.inventories: ~0 rows (approximately)
DELETE FROM `inventories`;
/*!40000 ALTER TABLE `inventories` DISABLE KEYS */;
/*!40000 ALTER TABLE `inventories` ENABLE KEYS */;
-- Dumping structure for table database.recipes
DROP TABLE IF EXISTS `recipes`;
CREATE TABLE IF NOT EXISTS `recipes` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`name` varchar(250) NOT NULL,
`cooking` longtext NOT NULL,
PRIMARY KEY (`id`),
KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Dumping data for table database.recipes: ~0 rows (approximately)
DELETE FROM `recipes`;
/*!40000 ALTER TABLE `recipes` DISABLE KEYS */;
/*!40000 ALTER TABLE `recipes` ENABLE KEYS */;
-- Dumping structure for table database.unities
DROP TABLE IF EXISTS `unities`;
CREATE TABLE IF NOT EXISTS `unities` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`name` varchar(50) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Dumping data for table database.unities: ~0 rows (approximately)
DELETE FROM `unities`;
/*!40000 ALTER TABLE `unities` DISABLE KEYS */;
/*!40000 ALTER TABLE `unities` ENABLE KEYS */;
/*!40014 SET FOREIGN_KEY_CHECKS=1 */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

Je m'excuse pour le retard à répondre, comment voulez-vous utiliser le nom de domaine sur les unités de la table? Au début, je pensais que vous l'utiliser pour dire quel type de terrain vous avez été unificateur (que ce soit une recette, recipe_ingredient, ou d'un ingrédient), mais ensuite j'ai vu qu'il était unique. Merci pour votre réponse, c'est intéressant!
le nom est juste le nom de l'unité, par exemple L pour L, mL millilitre, g grammes et ainsi de suite, en fait, c'est le champ "nom" est le champ d'affichage pour votre "liste déroulante". Il doit être unique, imaginez que vous souhaitez comparer l'unité utilisée dans les recettes et celui que vous utilisez pour vous l'inventaire de référence pour chaque unité doit être unique. juste pour faire un parallelle, de ne pas être unique pour ce type de champ vous laisserait par exemple pour une application frontend avec 3 fois "kg" dans la liste déroulante... lequel allez-vous choisir ? la contrainte unique qui ne vous laissera pas de reproduire une telle données.

OriginalL'auteur guignol

0

Vous aurez besoin de trois tables: une recipes table, un ingredients table, et un recipe_ingredients tableau qui attribue les ingrédients d'une recette. Vous pouvez également stocker des informations supplémentaires dans ce tableau, comme les quantités. Ainsi, par exemple, si vous avez une recette de soupe de légumes, vous avez plusieurs entrées pour les légumes avec les quantités correspondantes. Ces entrées seraient alors liés à la recette et les ingrédients par l'intermédiaire d'une clé étrangère.

EDIT: Schéma à sa plus simple:
```
CREATE TABLE `ingredients` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(45) NOT NULL,
PRIMARY KEY (`id`)
) TYPE=InnoDB;
CREATE TABLE `recipes` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(45) NOT NULL,
PRIMARY KEY (`id`)
) TYPE=InnoDB;
CREATE TABLE `recipe_ingredients` (
`recipe_id` int(10) unsigned NOT NULL,
`ingredient_id` int(10) unsigned NOT NULL,
`quantity` int(10) unsigned NOT NULL,
KEY `recipe_id` (`recipe_id`),
KEY `ingredient_id` (`ingredient_id`)
) TYPE=InnoDB;
ALTER TABLE `recipe_ingredients`
ADD CONSTRAINT `recipe_ingredients_ibfk_2` FOREIGN KEY (`ingredient_id`) REFERENCES `ingredients` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
ADD CONSTRAINT `recipe_ingredients_ibfk_1` FOREIGN KEY (`recipe_id`) REFERENCES `recipes` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;
```
ainsi, dans le recipe_ingredients table, vous disposez de deux nullable des clés étrangères l'une à l'un des ingrédients de la table et une recette de table? Puis il suffit de remplir celle qui est pertinente pour recipe_ingredient?
Je n'aurais pas nullable clés étrangères que la table serait attribution d'un ingrédient pour une recette efficace, de sorte que les deux clés étrangères sera rempli. Si vous n'avez pas un ingrédient, il ne peut pas être attribué à une recette.
À l'aide de ce schéma, comment utiliser les "la sauce marinara" (une recette) comme ingrédient dans une autre recette?
Je vois. Dans ce cas, vous pourriez avoir deux colonnes dans votre recipe_ingredients table: ingredient_type (un ENUM colonne soit avec des ”ingrédients“ ou ”recette“ comme valeur), puis un item_id colonne qui contient la clé étrangère ID de l'enregistrement, de la ingredients de la table ou de la recipes table.
Raison pour voter?

OriginalL'auteur Martin Bean

D'une seule manière.

Dish
Key ID Name
1   1  Snails in Marinara Sauce
2   2  Marinara Sauce
3   3  Glass of Water
Ingredient
Key DISHID Name
1   NULL   Snail
2   NULL   Tomato
3   NULL   Onion
4   NULL   Evian
5   2      Marinara Sauce
Recipe
DishID IngredientKey Qty UOM
1      1             6   Each
1      5             3   TblSpoon
2      2             2   Each
2      3             1   Each
3      4             275 Millilitres

Donc, si un ingrédient est un plat, il a une recette.

Modifié après une question de l'OP, qui pointait vers un petit défaut dans ma réponse potentielle.

Comment identifier que l'ingrédient appelé 'Marinara Sauce' est en fait le même que le plat du même nom?
DishID = IngredientID, dans le ci-dessus, hmm, tiens.

OriginalL'auteur Tony Hopkinson

Vous devez vous connecter pour publier un commentaire.