kyuno/batchCooking
1
0
Fork 0
Code Issues 5 Pull requests Projects Releases Packages Wiki Activity Actions
batchCooking/specs/batch-cooking-modele.md
kyuno053 b90817b8e1
Add specs + Prisma schema for the documented data model (#3) 
* 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).
2026-08-16 12:23:59 +02:00

5.3 KiB
Raw Permalink Blame History

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

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.