Datenbankschema für eine ToDo-Liste

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

Wie geht das am besten?

1. Eine neue Tabelle für jede Liste, die die Elemente enthält.

oder

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

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

F Wie zählt ein BASIC-Codierer bis 10?
A 1,2,3,4,5,6,7,8,9,10

F Wie zählt ein C-Codierer bis 10?
A 0,1,2,3,4,5,6,7,8,9

F Wie zählt ein DBA bis 10?
A 0,1, viele

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

Ein Schema, das so aussieht:

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

Liegt falsch, denn wo willst du eine dritte Telefonnummer eintragen, wenn jemand sie hat?

Gleiches gilt für die 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 Gegenstände.

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 sie zu unterstützen. Abgeschlossen, Fälligkeitsdatum, Wiederholung usw. Dies sind zusätzliche Strukturen, die bei der Gestaltung der Tabelle berücksichtigt werden müssen. Das heißt, wenn die Tabellenstruktur nicht angemessen normalisiert ist (oder Sie die Kompromisse realisieren, die Sie gemacht haben, weil sie nicht normalisiert sind), werden Sie später viele Kopfschmerzen haben.

Alles, was sich darauf bezieht, dies als relationale Datenbank zu schreiben. Aber das ist nicht die einzige Art von Datenbank da draußen. 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 sehr damit befassen, aber es gibt zahlreiche Tutorials, in denen Sie ToDo-Listen auf der Couch erstellen können. Eine solche, die mit einer Suche kam, ist eine einfache Aufgabenlisten-Anwendung 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 fügen die Liste einfach in ein JSON-Objekt ein und fügen sie in die Datenbank ein. Und dann liest du aus der Datenbank.

Der JSON könnte so 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 der Erstellung einer Einkaufsliste mit einer JSON-Datei auf Stack Overflow).

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

Die Sache ist, es ist nicht der falsche Weg zu Ansatz und eine To - do - Liste in einer Dokumentendatenbank können perfekt geeignet sein , was Sie versuchen , mit weniger Aufwand Konzept zu tun , für wie es zu tun.

Option 2 ist ein traditionelles Master / Detail-Setup. Das ist wahrscheinlich, was Sie hier wollen. Fügen Sie die Listen-ID in die Artikeltabelle ein und fügen Sie sie hinzu. 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)

Ich würde nicht versuchen, Ihre Benutzeroberflächendarstellung oder Datenübertragung direkt an die Art und Weise zu binden, in der 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 auf einfache Weise beide Seiten wechseln, ohne dass sich dies kritisch auf die andere auswirkt.

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 eingeteilt 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 in einer Ergebnismenge zusammenzufassen. Anschließend müssen Sie das Ergebnis wiederholen und eine JSON-Antwort generieren, die Ihren Benutzeroberflächenanforderungen entspricht. Was Sie wahrscheinlich tun möchten, ist, die Daten so in JSON einzugeben, dass sie Ihren Benutzeroberflächenanforderungen so gut wie möglich entsprechen. Dadurch wird häufig die Notwendigkeit zusätzlicher Skriptlogik auf Ihren Webseiten beseitigt.