it-swarm.com.de

Datenbankschema für eine Aufgabenliste

Ich versuche, eine sehr einfache Aufgabenlistenanwendung mit PHP, MySQL, Jquery-Templating und JSON zu erstellen ... Mein Schema scheint jedoch die Dinge in JSON zu komplizieren.

Was ist der beste Weg, um es zu tun?

  1. Eine neue Tabelle für jede Liste mit den Elementen.

oder

  1. eine Tabelle für Listen und eine Tabelle für Elemente, die irgendwie verbunden sind? Weil ich es versucht habe und es nicht der richtige Weg zu sein scheint? Beispiel http://jsfiddle.net/Lto3xuhe/
15
CodeSlow

Es gibt einen Witz, den ich vor einiger Zeit gehört habe:

[~ # ~] q [~ # ~] Wie zählt ein BASIC-Codierer bis 10?
[~ # ~] a [~ # ~] 1,2,3,4,5,6,7,8, 9,10

[~ # ~] q [~ # ~] Wie zählt ein C-Codierer bis 10?
[~ # ~] a [~ # ~] 0,1,2,3,4,5,6,7, 8,9

[~ # ~] q [~ # ~] Wie zählt ein DBA bis 10?
[~ # ~] a [~ # ~] 0,1, viele

Die Wahrheit hinter diesem Witz ist, dass Sie es falsch machen, wenn Sie zwei (oder mehr) derselben Sache in einer Datenbankstruktur (Spalten oder Tabellen) haben.

Ein Schema, das aussieht wie:

+----------+
| id       |
| name     |
| phone1   |
| phone2   |
|          |
+----------+

Ist falsch, denn wo werden Sie eine dritte Telefonnummer setzen, wenn jemand sie hat?

Gleiches gilt für Tabellen selbst. Es ist auch eine schlechte Sache, das Schema zur Laufzeit zu ändern, was die "neue Tabelle für jede Liste" zu implizieren scheint. (Siehe auch: MVC4: Wie erstelle ich ein Modell zur Laufzeit? )

Daher besteht die Lösung darin, eine Aufgabenliste zu erstellen, die aus zwei Tabellen besteht. Sie haben zwei Dinge - Listen und Elemente.

Erstellen wir also eine Tabellenstruktur, die dies widerspiegelt:

+----------+       +-------------+
| List     |       | Task        |
+----------+       +-------------+
| id (pk)  <---+   | id (pk)     |
| name     |   +---+ listid (fk) |
|          |       | desc        |
|          |       |             |
+----------+       +-------------+

Die Liste hat eine ID (den Primärschlüssel für die Liste) und einen Namen. Die Aufgabe hat eine ID (den Primärschlüssel), eine Listen-ID (einen Fremdschlüssel) und die Beschreibung der Aufgabe. Der Fremdschlüssel bezieht sich auf den Primärschlüssel einer anderen Tabelle.

Ich werde darauf hinweisen, dass dies nicht alle Möglichkeiten in verschiedenen Anforderungen für die Software und die Tabellenstruktur umfasst, um dies zu unterstützen. Abgeschlossen, Fälligkeitsdatum, Wiederholung usw. Dies sind alles zusätzliche Strukturen, die beim Entwerfen der Tabelle wahrscheinlich berücksichtigt werden müssen. Das heißt, wenn die Tabellenstruktur nicht angemessen normalisiert ist (oder wenn Sie die Kompromisse erkennen, die Sie gemacht haben, weil sie nicht normalisiert sind), werden Sie später viele Kopfschmerzen haben.


Alles, was damit zu tun hat, dies als relationale Datenbank zu schreiben. Dies ist jedoch nicht die einzige Art von Datenbank. Wenn Sie eine Liste als Dokument betrachten, bieten die nosql-Datenbanken im Dokumentstil möglicherweise auch einen Ansatz, der nicht falsch ist.

Ich werde mich zwar nicht zu weit damit befassen, aber es gibt zahlreiche Tutorials für Aufgabenlisten auf der Couch. Eine solche, die zu einer Suche kam, ist Eine einfache Anwendung mit Aufgabenlisten in CouchDB . Ein weiteres wird im Couchdb-Wiki angezeigt: Vorgeschlagenes Schema für Aufgabenlisten .

Bei dem für eine Couch geeigneten Ansatz ist jede Liste ein in der Datenbank gespeichertes JSON-Dokument. Sie würden die Liste einfach in ein JSON-Objekt einfügen und in die Datenbank einfügen. Und dann lesen Sie aus der Datenbank.

Der JSON könnte folgendermaßen aussehen:

[
 {"task":"get milk","who":"Scott","dueDate":"2013-05-19","done":false},
 {"task":"get broccoli","who":"Elisabeth","dueDate":"2013-05-21","done":false},
 {"task":"get garlic","who":"Trish","dueDate":"2013-05-30","done":false},
 {"task":"get eggs","who":"Josh","dueDate":"2013-05-15","done":true}
]

(von Erstellen einer Einkaufsliste mit einer JSON-Datei bei Stapelüberlauf).

Oder etwas, das sich dem nähert. Es gibt einige andere Aufzeichnungen, die die Couch als Teil des Dokuments hat.

Die Sache ist, es ist nicht die falsche Vorgehensweise und eine Aufgabenliste in einer Dokumentendatenbank ist möglicherweise perfekt für das geeignet, was Sie mit weniger Konzeptaufwand für wie tun möchten.

67
user40980

Option 2 ist ein traditionelles Master-/Detail-Setup. Das ist wahrscheinlich das, was Sie hier wollen. Fügen Sie die Listen-ID in die Elementtabelle ein und schließen Sie sich dieser an. Das Schema sollte sich nicht auf JSON auswirken. Ihre Anfrage könnte ungefähr so ​​aussehen:

select lists.name as list_name, items.name as item_name 
from items 
join lists on (lists.id = items.list_id)
6
GrandmasterB

Ich würde nicht versuchen, Ihre UI-Darstellung oder Datenübertragung direkt mit der Art und Weise zu verknüpfen, wie Sie die Daten speichern möchten. Indem Sie die beiden getrennt halten und eine Middleware-Logik verwenden, um die beiden zu heiraten, können Sie problemlos beide Seiten ändern, ohne die andere möglicherweise kritisch zu beeinflussen.

Aus Sicht der Datenspeicherung würden Sie wahrscheinlich Option 2 verwenden, die dem typischen normalisierten Datenmuster folgt, bei dem gemeinsame Teile in ihre eigenen Tabellen zerlegt werden, um Wiederholungen zu vermeiden und das Aufblähen der Datenbank zu minimieren.

Aus Sicht der Ansicht müssen Sie lediglich eine Datenbankabfrage verwenden, um die relevanten Daten zu einer Ergebnismenge zusammenzufügen und dieses Ergebnis dann zu iterieren und eine JSON-Antwort zu generieren, die auf Ihre Benutzeroberflächenanforderungen anwendbar ist. Sie möchten die Daten wahrscheinlich so in JSON einspeisen, dass sie Ihren Benutzeroberflächenanforderungen so gut wie möglich entsprechen, sodass häufig keine zusätzliche Skriptlogik auf Ihren Webseiten erforderlich ist.

3
Naros