Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:dokumentdb [2015/10/05 21:19] – [Datenmodell] brueck
+++ bigdata:dokumentdb [2015/10/05 21:19] (aktuell) – [Nachteile] brueck
@@ Zeile 23: / Zeile 23: @@
 ===== Nachteile =====
-Auch hier ist es nicht ohne Weiteres möglich, Beziehungen zwischen den Dokumenten herzustellen. Es ist zwar möglich, ID-Felder in die Dokumente zu schreiben, jedoch sind darüber keine Direkten JOINs möglich, da zunächst ein Dokument geladen und nach der ID gesucht wird und dann im nächsten Schritt erneut die Datenbank befragt werden muss, um ein Dokument mit der passenden ID zu suchen und zu laden, um dann eine Schnittmenge zu erstellen. Da es sich um ein nichtrelationales Modell handelt, bietet die Datenbank dafür auch keinerlei Abfragemöglichkeiten und müssen daher selbst programmiert werden. Für Anwendungen, bei denen komplexere Beziehungen wichtig sind, eignen sie sich also eher nicht. Während die Schemafreiheit einerseits zwar große Flexibilität bei der Modellierung bietet, bedeutet sie andererseits jedoch Aufwand bei der Abfrageprogrammierung, da zuvor der Applikationscode studiert werden muss, um Einblicke über das indirekte Schema der Datenbank gewinnen zu können ([[bigdata:literatur|Sadalage/Fowler 2012: S. 29]]). Zudem müssen Festlegungen zu Dokumentenstrukturen, eventuelle Wertprüfungen, Trigger und dergleichen in der Anwendung programmiert werden und können nicht von der Datenbank selbst übernommen werden.
+Auch hier ist es nicht ohne Weiteres möglich, Beziehungen zwischen den Dokumenten herzustellen. Es ist zwar möglich, ID-Felder in die Dokumente zu schreiben, jedoch sind darüber keine Direkten JOINs möglich, da zunächst ein Dokument geladen und nach der ID gesucht wird und dann im nächsten Schritt erneut die Datenbank befragt werden muss, um ein Dokument mit der passenden ID zu suchen und zu laden, um dann eine Schnittmenge zu erstellen. Da es sich um ein nichtrelationales Modell handelt, bietet die Datenbank dafür auch keinerlei Abfragemöglichkeiten und müssen daher selbst programmiert werden. Für Anwendungen, bei denen komplexere Beziehungen wichtig sind, eignen sie sich also eher nicht. Während die Schemafreiheit einerseits zwar große Flexibilität bei der Modellierung bietet, bedeutet sie andererseits jedoch Aufwand bei der Abfrageprogrammierung, da zuvor der Applikationscode studiert werden muss, um Einblicke über das indirekte Schema der Datenbank gewinnen zu können ([[bigdata:literatur#s|Sadalage/Fowler 2012: S. 29]]). Zudem müssen Festlegungen zu Dokumentenstrukturen, eventuelle Wertprüfungen, Trigger und dergleichen in der Anwendung programmiert werden und können nicht von der Datenbank selbst übernommen werden.