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.

Die Standard-Units müssen mitgeführt werden, damit jedem Food/Recipe auch seine Standard-Unit zugeordnet werden muss:

• _id
• title (Bezeichnung als String)
  • GRAM
  • MILLILITER
  • PORTION

Ein Benutzer kann eigene Units anlegen. Diese Units beziehen sich immer direkt auf ein Food/Recipe.

• _id
• title
• food._id/recipe._id
• amount
• basicUnit._id

• bitwall:
  • 1 Food-Tabelle
    • _id
    • title
    • kcal
    • protein
    • carb
    • basicUnit._id
  • 1 Recipe-Tabelle
    • _id
    • title
    • basicUnit._id
  • 1 Relation-Tabelle (n:m)
    • _id
    • recipe._id
    • food._id
• user (analog zu bitwall-Tabellen):
  • 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.

• 1 entry hat n meals
• 1 meal hat 1-n foods oder recipes
  • hier handelt es sich um Kopien und keine Referenzen
  • Fraglich: Was wie kopieren? → Redundanzen vermeiden!