* Add project specs, gitignore the source PDF specs/batch-cooking-architecture.md and specs/batch-cooking-modele.md are the clean markdown transcription of "Projet batch cooking.pdf" (a scanned/image-only PDF, no extractable text). The PDF itself is gitignored — source working document, not meant to be committed. * Add Prisma schema for the documented data model Models every table from specs/batch-cooking-modele.md: users/household (user_profiles, house, diet, allergy, category), planning (planning, planning_item), and recipes (recipe, ingredients, step, tech_step, tech_step_mapping, sources). Two deliberate deviations from the literal spec doc, per project discussion: - recipe_ingredient (recipe <-> ingredients) carries quantity + unit. The spec describes a plain many-to-many with no extra fields, but a shopping list / batch-cooking calculation needs quantities. - step is modeled one-to-many from recipe (not many-to-many as labeled in the doc): the documented `order` column only makes sense scoped to a single recipe, which isn't reconcilable with steps being shared across recipes. Everything else follows the doc as-is, including field nullability choices made where the doc doesn't specify (e.g. user_profiles.house_id optional, recipe.source_id optional) and onDelete behavior (Cascade for owned child records, SetNull for optional references) — first draft, not meant as final production hardening. Verified: `prisma validate`, `prisma generate`, and a real `prisma migrate dev` against a local Postgres (via docker-compose) — the migration applies cleanly and produces the expected schema. README: documents the migrate command and a Postgres port-conflict gotcha hit during validation (a native Postgres service on this machine was already bound to 5432, intercepting the Docker container's connections). * Add COMMENT ON for every table and column in the init migration Descriptions pulled from specs/batch-cooking-modele.md's per-table field tables. The two tables not in the original spec (join tables recipe_ingredient, user_profile_allergy) get a comment explaining why they exist. Amends the still-unmerged init migration directly rather than adding a follow-up migration, since it hasn't been applied anywhere but this local dev database. Verified: `prisma migrate reset --force` reapplies cleanly, and a query against pg_description confirms every column of every project table has a comment (only Prisma's own internal _prisma_migrations table is uncommented, out of scope).
251 lines
5.3 KiB
Markdown
251 lines
5.3 KiB
Markdown
# Modèle de données — Projet Batch-cooking
|
|
|
|
> Documentation du schéma de données de l'application de planification de batch-cooking.
|
|
|
|
---
|
|
|
|
## Vue d'ensemble
|
|
|
|
Le modèle s'articule autour de trois grands pôles :
|
|
|
|
- **Utilisateurs & foyer** — `user_profiles`, `house`, `diet`, `allergy`, `category`
|
|
- **Planification** — `planning`, `planning_item`
|
|
- **Recettes** — `recipe`, `ingredients`, `step`, `tech_step`, `tech_step_mapping`, `sources`
|
|
|
|
---
|
|
|
|
## Schéma entité-relation
|
|
|
|
```mermaid
|
|
erDiagram
|
|
USER_PROFILES }o--|| HOUSE : "vit dans"
|
|
USER_PROFILES }o--|| DIET : "suit"
|
|
HOUSE ||--o{ PLANNING : "planifie"
|
|
PLANNING ||--o{ PLANNING_ITEM : "contient"
|
|
PLANNING_ITEM }o--|| RECIPE : "utilise"
|
|
RECIPE }o--|| SOURCES : "vient de"
|
|
CATEGORY ||--o{ ALLERGY : "classe"
|
|
USER_PROFILES }o--o{ ALLERGY : "a"
|
|
RECIPE }o--o{ INGREDIENTS : "compose de"
|
|
RECIPE }o--o{ STEP : "compose de"
|
|
STEP }o--|| TECH_STEP : "utilise"
|
|
TECH_STEP ||--o{ TECH_STEP_MAPPING : "mappe"
|
|
INGREDIENTS }o--|| RECIPE : "recette alternative"
|
|
|
|
USER_PROFILES {
|
|
int id PK
|
|
string first_name
|
|
string last_name
|
|
string email
|
|
int house_id FK
|
|
int diet_id FK
|
|
}
|
|
HOUSE {
|
|
int id PK
|
|
string name
|
|
}
|
|
PLANNING {
|
|
int id PK
|
|
date start_date
|
|
date finish_date
|
|
int house_id FK
|
|
}
|
|
PLANNING_ITEM {
|
|
int id PK
|
|
int planning_id FK
|
|
string week_day
|
|
string meal
|
|
int recipe_id FK
|
|
}
|
|
DIET {
|
|
int id PK
|
|
string name
|
|
}
|
|
ALLERGY {
|
|
int id PK
|
|
int cat_id FK
|
|
}
|
|
CATEGORY {
|
|
int id PK
|
|
string name
|
|
}
|
|
INGREDIENTS {
|
|
int id PK
|
|
string name
|
|
string icon
|
|
int alternate_recipe FK
|
|
}
|
|
RECIPE {
|
|
int id PK
|
|
string name
|
|
int source_id FK
|
|
string description
|
|
string picture
|
|
}
|
|
STEP {
|
|
int id PK
|
|
string description
|
|
string picture
|
|
int order
|
|
int tech_step_id FK
|
|
}
|
|
TECH_STEP {
|
|
int id PK
|
|
}
|
|
TECH_STEP_MAPPING {
|
|
int id PK
|
|
int tech_step_id FK
|
|
string expression
|
|
int weight
|
|
}
|
|
SOURCES {
|
|
int id PK
|
|
string name
|
|
string url
|
|
}
|
|
```
|
|
|
|
*(Rendu sur les visualiseurs markdown compatibles mermaid — GitHub, VS Code, Obsidian, etc.)*
|
|
|
|
---
|
|
|
|
## Tables
|
|
|
|
### `user_profiles`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `first_name` | Prénom |
|
|
| `last_name` | Nom |
|
|
| `email` | Email |
|
|
| `house_id` | FK → `house` |
|
|
| `diet_id` | FK → `diet` |
|
|
|
|
### `house`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `name` | Nom du foyer |
|
|
|
|
### `diet`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `name` | Nom du régime alimentaire |
|
|
|
|
### `allergy`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `cat_id` | FK → `category` |
|
|
|
|
Associée à `user_profiles` en many-to-many (table de jointure simple, sans champ additionnel).
|
|
|
|
### `category`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `name` | Nom de la catégorie |
|
|
|
|
Table d'énumération, destinée à grandir au fil du projet (portera notamment les nuances liées aux allergies).
|
|
|
|
### `planning`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `start_date` | Date de début |
|
|
| `finish_date` | Date de fin |
|
|
| `house_id` | FK → `house` |
|
|
|
|
### `planning_item`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `planning_id` | FK → `planning` |
|
|
| `week_day` | Jour de la semaine |
|
|
| `meal` | Repas concerné |
|
|
| `recipe_id` | FK → `recipe` |
|
|
|
|
### `recipe`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `name` | Nom de la recette |
|
|
| `source_id` | FK → `sources` |
|
|
| `description` | Description |
|
|
| `picture` | Image |
|
|
|
|
Associée à `ingredients` en many-to-many.
|
|
|
|
### `ingredients`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `name` | Nom |
|
|
| `icon` | Icône |
|
|
| `alternate_recipe` | FK → `recipe` (recette alternative) |
|
|
|
|
### `step`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `description` | Description de l'étape |
|
|
| `picture` | Image |
|
|
| `order` | Ordre dans la recette |
|
|
| `tech_step_id` | FK → `tech_step` |
|
|
|
|
Associée à `recipe` en many-to-many.
|
|
|
|
### `tech_step`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
|
|
### `tech_step_mapping`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `tech_step_id` | FK → `tech_step` |
|
|
| `expression` | Expression |
|
|
| `weight` | Poids |
|
|
|
|
### `sources`
|
|
| Champ | Description |
|
|
|---|---|
|
|
| `id` | Identifiant |
|
|
| `name` | Nom de la source |
|
|
| `url` | URL |
|
|
|
|
---
|
|
|
|
## Relations
|
|
|
|
### Many-to-one (clés étrangères)
|
|
|
|
| Table source | Champ FK | Table cible |
|
|
|---|---|---|
|
|
| `user_profiles` | `house_id` | `house` |
|
|
| `user_profiles` | `diet_id` | `diet` |
|
|
| `planning` | `house_id` | `house` |
|
|
| `planning_item` | `planning_id` | `planning` |
|
|
| `planning_item` | `recipe_id` | `recipe` |
|
|
| `allergy` | `cat_id` | `category` |
|
|
| `ingredients` | `alternate_recipe` | `recipe` |
|
|
| `recipe` | `source_id` | `sources` |
|
|
| `step` | `tech_step_id` | `tech_step` |
|
|
| `tech_step_mapping` | `tech_step_id` | `tech_step` |
|
|
|
|
### Many-to-many (associations)
|
|
|
|
| Table A | Table B | Détail |
|
|
|---|---|---|
|
|
| `user_profiles` | `allergy` | Table de jointure simple |
|
|
| `recipe` | `ingredients` | Composition d'une recette |
|
|
| `step` | `recipe` | Étapes d'une recette |
|
|
|
|
---
|
|
|
|
## Règles de modélisation
|
|
|
|
- Toute relation qualifiée d'**« association »** entre deux tables est une relation **many-to-many**.
|
|
- `category` est une table d'énumération, amenée à grandir au fur et à mesure du projet.
|