Einführung in Datenbanken¶
Info
Sind Sie ein erfahrener Entwickler und wissen bereits alles über Datenbanken? 🤓
Dann können Sie direkt zu den nächsten Abschnitten springen.
Wenn Sie noch nicht alles über Datenbanken wissen, hier ist ein kurzer Überblick.
Sie können später immer noch viel mehr selbständig lernen.
Aber das sollte Ihnen helfen, mit Datenbanken zu beginnen und mit SQLModel produktiv zu werden. 🚀
Was ist eine Datenbank¶
Also, was ist eine Datenbank?
Eine Datenbank ist ein System zur Speicherung und Verwaltung von Daten auf strukturierte und sehr effiziente Weise.
Tipp
Es ist sehr üblich, das Wort "Datenbank" als "DB" abzukürzen.
Da es viele Informationen über Datenbanken gibt und diese sehr technisch und akademisch sein können, gebe ich Ihnen hier einen kurzen Überblick über einige der Hauptkonzepte.
Ich werde Ihnen sogar einiges über verschiedene Arten von Datenbanken erzählen, einschließlich derjenigen, die nicht von SQLModel abgedeckt werden ("NoSQL"-Datenbanken).
Warum eine Datenbank verwenden¶
Wenn Sie mit dem Programmieren beginnen, ist es vielleicht nicht offensichtlich, warum eine separate Datenbank neben dem Code für Ihr Programm eine gute Idee ist. Beginnen wir damit.
Tipp
Wenn Ihnen das offensichtlich ist, fahren Sie einfach im nächsten Abschnitt unten fort. 👇
In Ihrem Code haben Sie bereits Variablen, Wörterbücher, Listen usw. Sie alle speichern auf irgendeine Weise Daten. Warum sollten Sie eine separate Datenbank benötigen?
Wenn Sie genau hinsehen, ist Ihr Code statisch, er ändert sich nicht wirklich im Laufe der Zeit, sobald Sie ihn ausführen. Natürlich ändern Sie den Code häufig, fügen Funktionen hinzu usw., aber sobald Sie Python mit Ihrem Code ausführen, bleibt das Programm so, wie es war, als Sie es gestartet haben. Und wenn Sie den Code ändern, ändert sich das Programm erst, wenn Sie es erneut ausführen.
Und selbst wenn Sie Dinge in Variablen ändern, sobald das Programm beendet ist, sind all diese Daten, die sich im Speicher befanden, weg. 🔥
In den meisten Fällen besteht das Ziel Ihres Programms darin, etwas mit Daten außerhalb des Programms zu tun.
- Es könnte einfach darin bestehen, Dateien von einem Ort zum anderen zu verschieben.
- Oder es könnte darin bestehen, Daten vom Benutzer im Terminal entgegenzunehmen und sie anders darzustellen.
- Oder eine Web-API, die Daten entgegennimmt und diese auf eine bestimmte Weise verarbeitet usw.
In den meisten Fällen stammen die Daten von außerhalb des Programms oder enden außerhalb des Programms (z. B. auf dem Bildschirm, in einer Datei usw.).
In vielen Fällen muss Ihr Programm Daten erstellen und speichern, sie lesen, aktualisieren, löschen usw. können.
Sie könnten all das tun, indem Sie von Ihrem Code aus Dateien lesen und in sie schreiben. Und das funktioniert in einfachen Fällen. Aber für die meisten komplexen Systeme mit etwas komplexeren Daten ist diese Strategie nicht sehr effizient. Und Sie müssten sich mit vielen Vorbehalten auseinandersetzen, die Daten synchron halten, sicherstellen, dass sie sicher gespeichert sind usw.
Datenbanken sind dazu gedacht, diese Probleme zu lösen, den Prozess der Datenverwaltung viel effizienter und unabhängig von Ihrem Code zu gestalten. ✨
Wie man mit einer Datenbank interagiert¶
Es gibt viele Datenbanken verschiedenster Art.
Eine Einzeldatei-Datenbank¶
Eine Datenbank könnte eine einzelne Datei namens heroes.db sein, die auf sehr effiziente Weise mit Code verwaltet wird. Ein Beispiel wäre SQLite, dazu später mehr.
Eine Server-Datenbank¶
Eine Datenbank könnte auch ein System sein, das als Anwendung auf einem Server läuft und intern mehrere Dateien in optimierten Formaten verwaltet.
Ähnlich wie ein Webserver, aber über eine benutzerdefinierte und sehr effiziente Schnittstelle kommuniziert. Dies ist die gebräuchlichste Art der Datenbankinteraktion.
In diesem Fall würde Ihr Code mit dieser Serveranwendung sprechen, anstatt Dateien direkt zu lesen oder zu ändern.
Die Datenbank könnte sich auf einem anderen Server/einer anderen Maschine befinden
Oder die Datenbank könnte sich auf demselben Server/derselben Maschine befinden
Der wichtigste Aspekt dieser Arten von Datenbanken ist, dass Ihr Code die Dateien, die die Daten enthalten, nicht direkt liest oder ändert.
Stattdessen kommuniziert Ihr Code mit der Datenbankanwendung, und diese Datenbankanwendung ist diejenige, die ihre Datendateien tatsächlich liest und ändert. Das liegt daran, dass diese Datenbankanwendung normalerweise viel effizienter ist als das, was Ihr Code leisten könnte.
Einige Beispiele für Datenbanken, die so funktionieren, sind PostgreSQL, MySQL oder MongoDB.
Verteilte Server¶
In einigen Fällen könnte die Datenbank sogar eine Gruppe von Serveranwendungen sein, die auf verschiedenen Maschinen laufen, zusammenarbeiten und miteinander kommunizieren, um effizienter zu sein und mehr Daten zu verarbeiten.
In diesem Fall würde Ihr Code mit einer oder mehreren dieser Serveranwendungen sprechen, die auf verschiedenen Maschinen laufen.
Die meisten Datenbanken, die als Serveranwendungen funktionieren, unterstützen auch auf die eine oder andere Weise mehrere Server.
Verteilte Systeme bringen auch zusätzliche Herausforderungen mit sich, daher ist es sehr wahrscheinlich, dass Sie zuerst mit einer einzelnen Serveranwendung oder einer auf einer einzelnen Datei basierenden Anwendung interagieren.
SQL-Datenbanken¶
Wir haben bereits über die verschiedenen Möglichkeiten der Interaktion mit einer Datenbank und deren Dateiverwaltung usw. gesprochen. Das gilt für die meisten oder alle Datenbanken.
Es gibt jedoch eine weitere, sehr wichtige Möglichkeit, Datenbanken zu kategorisieren. Wie Sie sich vorstellen können, gibt es viele Arten von Datenbanken und viele Datenbanken in jeder Gruppe. Aber im Allgemeinen können sie in zwei große Gruppen eingeteilt werden: "SQL-Datenbanken" und "NoSQL-Datenbanken".
Wir werden gleich darauf eingehen, warum der Name "SQL" ist, aber sehen wir uns zuerst an, worum es dabei geht.
SQLModel für SQL-Datenbanken¶
SQLModel ist ein Werkzeug, das Ihnen bei SQL-Datenbanken hilft.
Es kann Ihnen bei NoSQL-Datenbanken nicht viel helfen. Dennoch werde ich hier einiges darüber erklären.
Erfindung von SQL-Datenbanken¶
Vor langer Zeit erkannten einige kluge Leute, dass eine großartige Möglichkeit, Daten zu speichern, darin bestand, sie in verschiedene Tabellen zu legen.
Und mit "Tabelle" meine ich nur Daten in einem Raster mit verschiedenen Spalten und Zeilen, so ähnlich wie eine einzelne Tabelle in einem Tabellenkalkulationsprogramm.
Jede Zeile würde ein bestimmtes Element oder einen Datensatz darstellen. Und jede Spalte würde ein bestimmtes Attribut oder Feld dieses Datensatzes darstellen.
Ein Beispiel für eine große Tabelle¶
Stellen wir uns vor, wir müssen einige Daten über Helden speichern.
Wenn wir mit einer einzigen Tabelle arbeiten würden, um unsere Helden zu speichern, könnte das so aussehen
| id | name | secret_name | age | team | headquarters |
|---|---|---|---|---|---|
| 1 | Deadpond | Dive Wilson | null | Z-Factor | Sister Margaret's Bar |
| 2 | Spider-Boy | Pedro Parqueador | null | Preventers | Sharp Tower |
| 3 | Rusty-Man | Tommy Sharp | 48 | Preventers | Sharp Tower |
Das ist wahrscheinlich das, was wir mit einer einzigen Tabelle machen müssten, zum Beispiel mit einem einzigen Tabellenblatt.
Aber das birgt einige Probleme. Schauen wir uns einige davon an.
Probleme mit einer einzelnen Tabelle¶
Stellen Sie sich vor, sie beschließen, "Sharp Tower" in "Preventers Tower" umzubenennen.
Jetzt müssten wir das an zwei Stellen aktualisieren.
Was passiert, wenn unser Code beginnt, diesen Namen an einer Stelle zu aktualisieren, und plötzlich gibt es einen Stromausfall und der Computer geht aus?
Wir könnten inkonsistente Informationen erhalten, wobei eine Stelle "Preventers Tower" und die andere "Sharp Tower" anzeigt.
| id | name | secret_name | age | team | headquarters |
|---|---|---|---|---|---|
| 1 | Deadpond | Dive Wilson | null | Z-Force | Sister Margaret's Bar |
| 2 | Spider-Boy | Pedro Parqueador | null | Preventers | Preventers Tower ✅ |
| 3 | Rusty-Man | Tommy Sharp | 48 | Preventers | Sharp Tower 🚨 |
Und stellen Sie sich nun vor, wir müssen einen neuen Helden namens "Mahjong" hinzufügen, der zum Team "Z-Force" gehört.
Wir könnten den Namen des Teams vergessen und "Mahjong" mit einem ungültigen Teamnamen hinzufügen, zum Beispiel "Y-Force".
| id | name | secret_name | age | team | headquarters |
|---|---|---|---|---|---|
| 1 | Deadpond | Dive Wilson | null | Z-Force | Sister Margaret's Bar |
| 2 | Spider-Boy | Pedro Parqueador | null | Preventers | Preventers Tower |
| 3 | Rusty-Man | Tommy Sharp | 48 | Preventers | Sharp Tower |
| 4 | Mahjong | Neena Thurgirl | 31 | Y-Force 🚨 | Sister Margaret's Bar |
Und was ist, wenn ein einzelner Held zu zwei Teams gehört? Wir hätten keine einfache Möglichkeit, dies in eine einzige große Tabelle einzufügen.
Mehrere Tabellen¶
Aber diese und andere Probleme könnten besser gelöst werden, indem die Daten in mehreren Tabellen gespeichert werden.
Anstatt also eine einzige Tabelle mit allen Daten zu haben, könnten wir eine Tabelle für die Helden und eine für die Teams haben, und eine Möglichkeit, die beiden zu verbinden.
Die Tabelle für die Teams könnte so aussehen
| id | name | headquarters |
|---|---|---|
| 1 | Preventers | Sharp Tower |
| 2 | Z-Force | Sister Margaret's Bar |
Nun, die Tabelle für die Helden würde fast gleich aussehen. Aber erinnern Sie sich, dass wir erwähnt haben, dass wir eine Möglichkeit brauchen, die beiden Tabellen zu verbinden?
Die Tabelle für die Helden hätte nun eine weitere Spalte team_id. Diese Spalte zeigt die Beziehung jeder Zeile (jedes Helden) zum Team, dem sie angehört.
| id | name | secret_name | age | team_id ✨ |
|---|---|---|---|---|
| 1 | Deadpond | Dive Wilson | null | 2 ✨ |
| 2 | Spider-Boy | Pedro Parqueador | null | 1 ✨ |
| 3 | Rusty-Man | Tommy Sharp | 48 | 1 ✨ |
Identifikationen - Primärschlüssel¶
Im obigen Beispiel hat jede der Zeilen eine id. Jede ID ist pro Tabelle eindeutig und identifiziert diese spezielle Zeile.
Diese SQL-Datenbanken erfordern eine eindeutige Möglichkeit, jede Zeile in einer Tabelle zu identifizieren. Es kann eine Kombination von Spalten sein, die eindeutig ist, aber üblicherweise ist es nur eine einzelne Spalte. Dies wird als "Primärschlüssel" der Tabelle bezeichnet.
Der Primärschlüssel ist häufig eine einzelne Spalte, normalerweise eine von der Datenbank automatisch generierte Ganzzahl, und in vielen Fällen heißt die Spalte einfach id.
Dieser Primärschlüssel, in diesem Fall die Spalte id, muss pro Tabelle eindeutig sein. Aber zwei verschiedene Tabellen könnten dieselbe ID haben. Zum Beispiel haben beide Tabellen oben die ID 2 für zwei verschiedene Zeilen, eine für "Z-Force" in einer Tabelle und eine für "Spider-Boy" in der anderen Tabelle, aber das ist immer noch in Ordnung, solange es nur eine pro Tabelle gibt.
Beziehungen - Fremdschlüssel¶
Jede Zeile in einer Tabelle hat einen einzelnen Primärschlüssel (in unserem Beispiel eine einzelne Spalte id).
Zum Beispiel hat die Tabelle für die Teams die ID 1 für das Team Preventers und die ID 2 für das Team Z-Force.
Da diese Primärschlüssel-IDs jede Zeile in der Tabelle für Teams eindeutig identifizieren können, können wir nun zur Tabelle für Helden gehen und auf diese IDs in der Tabelle für Teams verweisen.
In der Tabelle für Helden verwenden wir also die Spalte team_id, um eine Beziehung zur fremden Tabelle für Teams herzustellen. Jeder Wert in der Spalte team_id in der Tabelle mit Helden ist derselbe Wert wie die Spalte id einer Zeile in der Tabelle mit Teams.
In der Tabelle für Helden haben wir einen Primärschlüssel, der die id ist. Aber wir haben auch eine weitere Spalte team_id, die sich auf einen Schlüssel in einer fremden Tabelle bezieht. Dafür gibt es auch einen Fachbegriff, die team_id ist ein "Fremdschlüssel".
Relationen und relationale Datenbanken¶
Der technische und akademische Begriff für jede dieser Tabellen ist eine "Relation".
Sie werden diesen Begriff wahrscheinlich oft hören, wenn Sie über diese Datenbanken sprechen.
Er hat nicht die Bedeutung, die Sie im Deutschen verwenden würden, dass etwas mit etwas anderem in Beziehung steht, auch wenn jede dieser Tabellen tatsächlich "verwandt" mit den anderen ist.
Der Fachbegriff Relation bezieht sich einfach auf jede dieser Tabellen.
Und aufgrund dieses Fachbegriffs werden diese SQL-Datenbanken auch relationale Datenbanken genannt (tatsächlich ist das der technisch korrekte Begriff). Aber er bezieht sich immer noch nur auf diese Datenbanken, die aus mehreren Tabellen bestehen.
SQL - Die Sprache¶
Nach der Entwicklung dieser Ideen zur Speicherung von Daten in mehreren Tabellen wurde auch eine Sprache entwickelt, mit der man mit ihnen interagieren konnte.
Die Sprache heißt SQL, der Name leitet sich von Structured Query Language ab.
Dennoch wird die Sprache nicht nur zum Abfragen von Daten verwendet. Sie wird auch zum Erstellen von Datensätzen/Zeilen, zum Aktualisieren und Löschen verwendet. Und zur Manipulation der Datenbank, zum Erstellen von Tabellen usw.
Diese Sprache wird von all diesen Datenbanken unterstützt, die mehrere Tabellen verwalten, weshalb sie SQL-Datenbanken genannt werden. Allerdings hat jede Datenbank kleine Variationen in der SQL-Sprache, die sie unterstützt (Dialekt).
Stellen wir uns vor, die Tabelle, die die Helden enthält, heißt hero-Tabelle. Ein Beispiel für eine SQL-Abfrage, um alle Daten daraus zu erhalten, könnte so aussehen
SELECT *
FROM hero;
Und diese SQL-Abfrage würde die Tabelle zurückgeben
| id | name | secret_name | age | team_id |
|---|---|---|---|---|
| 1 | Deadpond | Dive Wilson | null | 2 |
| 2 | Spider-Boy | Pedro Parqueador | null | 1 |
| 3 | Rusty-Man | Tommy Sharp | 48 | 1 |
SQLModel für SQL¶
SQLModel ist eine Bibliothek, die Ihnen hilft, Python-Code mit regulären Python-Objekten zu schreiben, und diese dann in SQL-Anweisungen umwandelt, die sie an eine SQL-Datenbank sendet.
Anschließend empfängt sie die Daten und wandelt sie in Python-Objekte um, die Sie in Ihrem Code weiterverwenden können.
Ich werde Ihnen in den nächsten Abschnitten mehr über SQL, SQLModel, deren Verwendung und ihre Beziehungen erzählen.
Technische Details
SQLModel basiert auf SQLAlchemy. Es ist tatsächlich nur SQLAlchemy und Pydantic gemischt mit etwas Zucker obendrauf.
NoSQL-Datenbanken¶
Obwohl SQL-Datenbanken der älteste und am weitesten verbreitete Datenbanktyp sind, gibt es eine weitere (sehr interessante) Kategorie, nämlich die der NoSQL-Datenbanken.
NoSQL-Datenbanken umfassen eine breite Palette verschiedener Untertypen, darunter Key-Value-Stores, Dokumentenspeicher, Graphdatenbanken und mehr.
SQLModel kann Ihnen nur bei SQL-Datenbanken helfen. Daher werden wir im Rest der Dokumentation darüber sprechen.