bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

Datenmodell finalisieren #2

New issue
Closed
opened 2026-05-13 12:25:45 +00:00 by jreinemann-euris · 3 comments
jreinemann-euris commented 2026-05-13 12:25:45 +00:00 (Migrated from github.com)
Copy link

Ziel

Room-Entities aus dem Anforderungsdokument ableiten und final festlegen.

Scope (enthalten)

  • Alle Room-Entities mit Feldern und Datentypen definieren (Items, Categories, Locations, …)
  • Beziehungen zwischen Entities (1:N, N:M)
  • Enums und Value-Types (z.B. Einheit, MHD-Format)

Akzeptanzkriterium

Entscheidung ist dokumentiert (Issue-Kommentar oder Anforderungen-Datei) und dient als Referenz für alle nachgelagerten Features.

## Ziel Room-Entities aus dem Anforderungsdokument ableiten und final festlegen. ## Scope (enthalten) - Alle Room-Entities mit Feldern und Datentypen definieren (Items, Categories, Locations, …) - Beziehungen zwischen Entities (1:N, N:M) - Enums und Value-Types (z.B. Einheit, MHD-Format) ## Akzeptanzkriterium Entscheidung ist dokumentiert (Issue-Kommentar oder Anforderungen-Datei) und dient als Referenz für alle nachgelagerten Features.
jreinemann-euris commented 2026-05-13 12:52:50 +00:00 (Migrated from github.com)
Copy link

Entschieden (2026-05-13)

Gewählt: Ansatz B - Pragmatisches Datenmodell

Begruendung: Beste Balance aus sauberer Normalisierung (Category, Location als verwaltbare Entities) und pragmatischer Vereinfachung (Unit als String, kein Unit-Overhead).

Finale Room-Entities

Category

  • id: Int PK AutoIncrement
  • name: String (benutzerdefiniert, z.B. Grundnahrungsmittel)

Location

  • id: Int PK AutoIncrement
  • name: String (benutzerdefiniert, z.B. Keller)

Item

  • id: String (UUID) - exportfreundlich, verteilte Systeme
  • name: String
  • categoryId: Int FK -> Category.id
  • quantity: Double
  • unit: String (kg, l, Stueck, Dosen ...)
  • unitPrice: Double
  • totalPrice: NICHT gespeichert, berechnet: quantity x unitPrice
  • kcalPer100g: Int? (nullable, nur fuer Lebensmittel)
  • expiryDate: LocalDate? (TypeConverter -> String ISO-8601, kompatibel mit JSON-Export)
  • locationId: Int FK -> Location.id
  • minStock: Double (gleiche Einheit wie quantity)
  • notes: String
  • lastUpdated: Long (Epoch-Millis)

Settings

  • key: String PK (z.B. persons, kcalPerPersonPerDay)
  • value: String (serialisiert)

Beziehungen

  • Item -> Category: N:1
  • Item -> Location: N:1

TypeConverter

  • LocalDate? <-> String? (ISO-8601: 2028-01-01) - direkt kompatibel mit JSON-Format

Berechnete Felder (nicht in DB)

  • totalPrice = quantity x unitPrice
  • totalKcal = (quantity_in_100g) x kcalPer100g
  • rangeInDays = totalKcal / (persons x kcalPerPersonPerDay)

Alternativen geprueft:

  • Ansatz A (Vollnormalisiert, Unit als Entity): Overhead ohne Mehrwert fuer v1.0
  • Ansatz C (Flach, alles String): Kategorieverwaltung nicht sauber umsetzbar
## Entschieden (2026-05-13) **Gewählt:** Ansatz B - Pragmatisches Datenmodell **Begruendung:** Beste Balance aus sauberer Normalisierung (Category, Location als verwaltbare Entities) und pragmatischer Vereinfachung (Unit als String, kein Unit-Overhead). --- ## Finale Room-Entities ### Category - id: Int PK AutoIncrement - name: String (benutzerdefiniert, z.B. Grundnahrungsmittel) ### Location - id: Int PK AutoIncrement - name: String (benutzerdefiniert, z.B. Keller) ### Item - id: String (UUID) - exportfreundlich, verteilte Systeme - name: String - categoryId: Int FK -> Category.id - quantity: Double - unit: String (kg, l, Stueck, Dosen ...) - unitPrice: Double - totalPrice: NICHT gespeichert, berechnet: quantity x unitPrice - kcalPer100g: Int? (nullable, nur fuer Lebensmittel) - expiryDate: LocalDate? (TypeConverter -> String ISO-8601, kompatibel mit JSON-Export) - locationId: Int FK -> Location.id - minStock: Double (gleiche Einheit wie quantity) - notes: String - lastUpdated: Long (Epoch-Millis) ### Settings - key: String PK (z.B. persons, kcalPerPersonPerDay) - value: String (serialisiert) --- ## Beziehungen - Item -> Category: N:1 - Item -> Location: N:1 ## TypeConverter - LocalDate? <-> String? (ISO-8601: 2028-01-01) - direkt kompatibel mit JSON-Format ## Berechnete Felder (nicht in DB) - totalPrice = quantity x unitPrice - totalKcal = (quantity_in_100g) x kcalPer100g - rangeInDays = totalKcal / (persons x kcalPerPersonPerDay) --- **Alternativen geprueft:** - Ansatz A (Vollnormalisiert, Unit als Entity): Overhead ohne Mehrwert fuer v1.0 - Ansatz C (Flach, alles String): Kategorieverwaltung nicht sauber umsetzbar
jreinemann-euris commented 2026-05-13 12:52:54 +00:00 (Migrated from github.com)
Copy link

Entschieden (2026-05-13)

Gewählt: Ansatz B - Pragmatisches Datenmodell

Begruendung: Beste Balance aus sauberer Normalisierung (Category, Location als verwaltbare Entities) und pragmatischer Vereinfachung (Unit als String, kein Unit-Overhead).

Finale Room-Entities

Category

  • id: Int PK AutoIncrement
  • name: String (benutzerdefiniert, z.B. Grundnahrungsmittel)

Location

  • id: Int PK AutoIncrement
  • name: String (benutzerdefiniert, z.B. Keller)

Item

  • id: String (UUID) - exportfreundlich, verteilte Systeme
  • name: String
  • categoryId: Int FK -> Category.id
  • quantity: Double
  • unit: String (kg, l, Stueck, Dosen ...)
  • unitPrice: Double
  • totalPrice: NICHT gespeichert, berechnet: quantity x unitPrice
  • kcalPer100g: Int? (nullable, nur fuer Lebensmittel)
  • expiryDate: LocalDate? (TypeConverter -> String ISO-8601, kompatibel mit JSON-Export)
  • locationId: Int FK -> Location.id
  • minStock: Double (gleiche Einheit wie quantity)
  • notes: String
  • lastUpdated: Long (Epoch-Millis)

Settings

  • key: String PK (z.B. persons, kcalPerPersonPerDay)
  • value: String (serialisiert)

Beziehungen

  • Item -> Category: N:1
  • Item -> Location: N:1

TypeConverter

  • LocalDate? <-> String? (ISO-8601: 2028-01-01) - direkt kompatibel mit JSON-Format

Berechnete Felder (nicht in DB)

  • totalPrice = quantity x unitPrice
  • totalKcal = (quantity_in_100g) x kcalPer100g
  • rangeInDays = totalKcal / (persons x kcalPerPersonPerDay)

Alternativen geprueft:

  • Ansatz A (Vollnormalisiert, Unit als Entity): Overhead ohne Mehrwert fuer v1.0
  • Ansatz C (Flach, alles String): Kategorieverwaltung nicht sauber umsetzbar
## Entschieden (2026-05-13) **Gewählt:** Ansatz B - Pragmatisches Datenmodell **Begruendung:** Beste Balance aus sauberer Normalisierung (Category, Location als verwaltbare Entities) und pragmatischer Vereinfachung (Unit als String, kein Unit-Overhead). --- ## Finale Room-Entities ### Category - id: Int PK AutoIncrement - name: String (benutzerdefiniert, z.B. Grundnahrungsmittel) ### Location - id: Int PK AutoIncrement - name: String (benutzerdefiniert, z.B. Keller) ### Item - id: String (UUID) - exportfreundlich, verteilte Systeme - name: String - categoryId: Int FK -> Category.id - quantity: Double - unit: String (kg, l, Stueck, Dosen ...) - unitPrice: Double - totalPrice: NICHT gespeichert, berechnet: quantity x unitPrice - kcalPer100g: Int? (nullable, nur fuer Lebensmittel) - expiryDate: LocalDate? (TypeConverter -> String ISO-8601, kompatibel mit JSON-Export) - locationId: Int FK -> Location.id - minStock: Double (gleiche Einheit wie quantity) - notes: String - lastUpdated: Long (Epoch-Millis) ### Settings - key: String PK (z.B. persons, kcalPerPersonPerDay) - value: String (serialisiert) --- ## Beziehungen - Item -> Category: N:1 - Item -> Location: N:1 ## TypeConverter - LocalDate? <-> String? (ISO-8601: 2028-01-01) - direkt kompatibel mit JSON-Format ## Berechnete Felder (nicht in DB) - totalPrice = quantity x unitPrice - totalKcal = (quantity_in_100g) x kcalPer100g - rangeInDays = totalKcal / (persons x kcalPerPersonPerDay) --- **Alternativen geprueft:** - Ansatz A (Vollnormalisiert, Unit als Entity): Overhead ohne Mehrwert fuer v1.0 - Ansatz C (Flach, alles String): Kategorieverwaltung nicht sauber umsetzbar
jreinemann-euris commented 2026-05-13 12:53:05 +00:00 (Migrated from github.com)
Copy link

Datenmodell finalisiert. Entscheidung im Kommentar oben dokumentiert.

Datenmodell finalisiert. Entscheidung im Kommentar oben dokumentiert.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
block-planning

   
bug

Something isn't working

  
documentation

Improvements or additions to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
feature

   
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
infrastructure

   
invalid

This doesn't seem right

  
planning

   
priority:high

   
priority:low

   
question

Further information is requested

  
refactoring

   
status:backlog

Im Backlog

  
status:done

Abgeschlossen

  
status:in-progress

Aktuell in Bearbeitung

  
status:todo

Naechstes Todo-Ticket

  
tech-decision

   
test

   
wontfix

This will not be worked on

No labels
block-planning
bug
documentation
duplicate
enhancement
feature
good first issue
help wanted
infrastructure
invalid
planning
priority:high
priority:low
question
refactoring
status:backlog
status:done
status:in-progress
status:todo
tech-decision
test
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: bollwerkadmin/bollwerk#2
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?