Differences

This shows you the differences between two versions of the page.

--- technical:db-design [2013/09/03 10:38] – angelegt martin
+++ technical:db-design [2013/09/03 21:01] (current) – [Food, Recipies] martin
@@ Line 1: / Line 1: @@
 ====== Datenbankentwurf ======
 ===== Grobe Aufteilung =====
-Es muss unterschieden werden zwischen Food, Recipes, Entries und Meals. 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.
+Es muss unterschieden werden zwischen **Food**, **Recipes**, **Entries** und **Meals**. Außerdem gibt es noch **Benutzer-Daten**. //**Fraglich:** Statistiken werden On-The-Fly berechnet.//
-Foods und Recipies wiederum müssen unterschieden werden zwischen bitwall- und User-Einträgen. Bitwall-Einträge werden mit der App mitgeliefert und manuell von den App-Produzenten gewartet. User-Einträge sind davon unabhängig. Diese Aufteilung ist sinnvoll, da Updates der Bitwall-Einträge die User-Einträge nicht berühren dürfen.
+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.
+===== Units =====
+==== Standard-Units ====
+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
+==== Custom-Units ====
+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
 ===== Food, Recipies =====
   * bitwall:
     * 1 Food-Tabelle
+      * _id
+      * title
+      * kcal
+      * protein
+      * carb
+      * basicUnit._id
     * 1 Recipe-Tabelle
+      * _id
+      * title
+      * basicUnit._id
     * 1 Relation-Tabelle (n:m)
-  * user:
+      * _id
+      * recipe._id
+      * food._id
+  * user (analog zu bitwall-Tabellen):
     * 1 Food-Tabelle
     * 1 Recipe-Tabelle
-    * 1 Relation-Tabelle
+    * 1 Relation-Tabelle (n:m)
 Der Benutzer muss aber beide Tabellen gleichzeitig durchsuchen können => Definition von 3 Views:
@@ Line 21: / Line 53: @@
   * 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
+So kann die komplette Tabelle food-/recipe-/relation-bitwall verändert werden, ohne dass die *-user-Tabellen angefasst werden.
+===== Entries, Meals =====
+  * 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!