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.

• 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