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 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.

5.3 KiB Raw Blame History

Modèle de données — Projet Batch-cooking

Vue d'ensemble

Schéma entité-relation

Tables

user_profiles

house

diet

allergy

category

planning

planning_item

recipe

ingredients

step

tech_step

tech_step_mapping

sources