Database Reference
In-Depth Information
Die Kosten der Flexibilität sind natürlich leere Einträge von Artikelnummer_2 und Bezie-
hungsstatus . Wie ärgerlich: Eine Preisänderung eines Artikels muss auch noch kommuni-
ziert werden. Eigentlich brauche ich nun auch noch eine Tabelle:
PREISAENDERUNG
Artikelnummer | alter_preis | neuer_preis
Mit ein wenig Nachdenken fallen jedem von uns noch mehr Beispiele von Nachrichten ein,
die zwischen Lieferanten und Kunden hin- und hergehen können. In einer relationalen Da-
tenbank müssen zuerst die Tabellen samt Beziehungen untereinander erzeugt, dann dieses
Schema den Programmierern zur Umsetzung in die Anwendung gegeben werden. Eine Da-
tenbank, die ohne Schema arbeitet, beschränkt sich dabei auf die Arbeit der Anwendungs-
programmierer (bzw. des Teams, das die Daten für die Anwendung liefert).
Wie also würde man so ein System in einer NoSQL-Datenbank wie CouchDB umsetzen?
(Ich benutze CouchDB hier exemplarisch für die Gattung der NoSQL-Datenbanken).
CouchDB kennt keine Tabellen und Beziehungen untereinander. Es gibt eine Datenbank
und dorthin schreibe ich ein Dokument. Ein Dokument besteht aus einem Datensatz, der
mindestens eine eindeutige ID und eine Revisionsnummer besitzt. Die „Nutzdaten“ des
Dokuments werden in Form von Feldern und Werten übergeben. Dabei gibt es in der Da-
tenbank keine Definition, welche Felder es gibt. Ein Händler gibt eine Nachricht an seine
Kunden, dass sich ein Preis erhöht hat? Die Nachricht dazu hätte das Format, das in Lis-
ting 1.1 zu sehen ist.
_id : (lfd. Nummer, von CouchDB vergeben)
_rev: (lft Nummer, von CouchDB vergeben)
Sender_id: 1
Empfaenger_id:123
Nachrichten_typ: 12 (Preiserhöhung)
Nachricht: "Der Preis des Artikels 12345 hat
sich von
100,- auf 105,- erhöht."
Artikelnummer: 12345
Preis_alt: 100
Preis_neu: 105
Search WWH ::




Custom Search