Page locked

This page is currently locked for editing by another user. You have to wait until this user finishes editing or the lock expires.

Currently locked by: 216.73.217.108,172.21.0.3
Lock expires at: 2026/09/06 08:47 (12 min)

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

====== Datenbankentwurf ======
===== Grobe Aufteilung =====
Es muss unterschieden werden zwischen **Food**, **Recipes**, **Entries** und **Meals**. Außerdem gibt es noch **Benutzer-Daten**. //**Fraglich:** Statistiken werden On-The-Fly berechnet.//

Food und Recipies stehen in einer n:m-Beziehung. Entries und Meals stehen in einer 1:n-Beziehung. Meals sind Kopien von Foods, bzw. Recipes, sind damit aber nicht verknüpft, da ansonsten Änderungen an Foods/Recipies alte Meals verändern würden.

Foods und Recipies wiederum müssen unterschieden werden zwischen **bitwall- und User-Daten**. Bitwall-Daten werden mit der App mitgeliefert und manuell von den App-Produzenten gewartet. User-Daten sind davon unabhängig. Diese Aufteilung ist sinnvoll, da Updates der Bitwall-Daten die User-Daten nicht berühren dürfen.

===== Food, Recipies =====
  * bitwall:
    * 1 Food-Tabelle
    * 1 Recipe-Tabelle
    * 1 Relation-Tabelle (n:m)
  * user:
    * 1 Food-Tabelle
    * 1 Recipe-Tabelle
    * 1 Relation-Tabelle (n:m)

Der Benutzer muss aber beide Tabellen gleichzeitig durchsuchen können => Definition von 3 Views:

  * food-view: select * from food-user UNION select * from food-bitwall
    * hier muss mit den Key-Values aufgepasst werden!
  * Recipe-View und Relation-View analog

So kann die komplette Tabelle food-/recipe-/relation-bitwall verändert werden, ohne dass die *-user-Tabellen angefasst werden