SQL – In einer SQL – Welt

Millionen von Entwicklern arbeiten mit SQL, SQL ist keine Datenbank Architektur, es ist lediglich ein Kürzel und steht für ″Structured Query Language″. Mit dieser Sprache können wiederum vordefinierte Abfragen auf Unsere Datenbank getätigt werden, wir können mit Join-Befehlen auch Daten aus verschiedenen Befehlen zusammenführen.

Hierzu ein kleines SQL – Beispiel:

Wir möchten die Registration von Usern ermöglichen, und wir möchten sehen an welchen Events dieser User teilnimmt. In einer SQL-Welt benötigen wir also drei Tabellen. Aus der ″UserEvents″
Tabelle kann man nun, dank den Fremdschlüssel und den Beziehungen() genau einsehen welcher User an welchem Event teilnimmt.

Beispiel für eine SQL-Abfrage

SELECT * FROM Users
Diese Abfrage gib uns alle in der User-Tabelle enthaltenen Users zurück.

SELECT * FROM Users WHERE Id = ‹6e1b4613-1b9c-454d-a4ba-9a9ba187d32c‹
Diese Abfrage gib uns einen spezifischen User zurück

NoSQL – In einer NoSQL – Welt

Die Wahl für eine, dem Projekt entsprechenden NoSQL Datenbank Struktur ist noch schwieriger als die Wahl zwischen NoSQL und SQL. Es gibt folgende NoSQL Strukturen:

• Key-Value
• Graph DB
• Column Family
• Document

Jede dieser Strukturen bieten eigene Framework Lösungen an z.B. für Dokument basierte Strukturen bieten Firebase und MongoDB eine Cloud Lösung an. Für Graphen basierte Strukturen betetet GraphQL eine Lösung an. Dokument basierte Lösungen werden jedoch am häufigsten verwendet.

Hierzu ein kleines NoSQL – Beispiel

Das Szenario bleibt gleich wie beim SQL-Szenario, wir haben unsere User, die an Events teilnehmen.
Wir benötigen also eine JSON-Struktur, die uns dies ermöglicht.
NoSQL-Basierte Datenbanken werden in einer JSON-Struktur aufgebaut.

User: {
UserId: ID
Name: STRING,
Address: STRING,
Email: STRING,
Events: {
[EventId]
}
}

Events: {
EventId: ID
Start: DATE,
End: DATE,
Title: STRING,
Description: STRING
}

Wir möchten nach wie vor sehen an welchen Events unsere User teilnehmen… bedeutet in einer NoSQL-Welt bauen wir dieses Szenario in einer JSON-Struktur auf. Wir haben also eine Kollektion mit Events und User. Bei der User Kollektion sehen wir ein Events Objekt, das ein Array von EventId’s aufnimmt, dieses Objekt wurde dupliziert, bedeutet wir haben die Datenbank denormalisiert.

In einer SQL-Welt wäre dies ein verehrender Fehler aber in einer NoSQL-Welt sind diese Demoralisierungen jedoch gewollt. Wir bauen also immer Daten-Strukturen die wir später Benötigen. Wir haben keine Structured Query Language, die es uns hier ermöglicht Daten aus mehreren Tabellen zusammen in der App anzuzeigen (Joins).

Nachteile sind das bei NoSQL-Queries keine Relationen in Betracht gezogen werden! Ich muss also Duplizierte Werte (in unserem Fall die EventId) bei einem Update, Delete oder Post so oft Überschreiben, Löschen, oder Hinzufügen wie es im Dokument vorkommt. Dies darf der Programmierer niemals ausser Acht lassen! NoSQL-Abfragen unterscheiden sich je nach gewähltem Framework.