Schlagwort-Archive: Datenbank
Date vs. Boolean
Beim Entwurf von Datenmodellen und den dazugehörigen Tabellen nutzen wir manchmal Boolean als Datentyp. Im Allgemeinen sind diese Flags nicht wirklich problematisch. Aber vielleicht gibt es eine bessere Lösung für dieses Datendesign. Lassen Sie mich, Ihnen ein kurzes Beispiel für meine Anliegen geben.
Nehmen wir an, wir müssen eine einfache Domäne zum Speichern von Artikeln entwerfen. Wie ein Blog-System oder ein Content-Management-System. Neben dem Inhalt des Artikels und dem Namen des Autors könnten wir ein Flag benötigen, das dem System mitteilt, ob der Artikel für die Öffentlichkeit sichtbar ist. So etwas wie veröffentlicht als boolescher Wert. Aber es gibt auch weitere Anforderung, ein Datum, wann für den Artikel die Veröffentlichung geplant ist. In den meisten Datenbankentwürfen, die ich beobachtet habe, gibt es für diese Umstände einen Boolean: published
und ein Datum: publishingDate
. Meiner Meinung nach ist dieses Design ein wenig redundant und auch fehleranfällig. Als schnelle Schlussfolgerung möchte ich eher dazu raten, von Anfang an nur Date anstelle von Boolean zu verwenden.
Das Szenario, das ich oben beschrieben habe, kann auch auf viele andere Domänenlösungen übertragen werden. Nachdem wir eine Vorstellung davon bekommen haben, warum wir Boolean durch den Datentyp Date ersetzen sollten, werden wir uns nun den Details widmen, wie wir dieses Ziel erreichen können.
Der Umgang mit Standard-SQL lässt vermuten, dass der Austausch eines Datenbankmanagementsystems (DBMS) gegen ein anderes kein großes Problem darstellen sollte. Die Realität sieht leider ein wenig anders aus. Nicht alle verfügbaren Datentypen für Datum wie Timestamp sind wirklich empfehlenswert zu verwenden. Aus Erfahrung ziehe ich es vor, das einfache java.util.Date zu verwenden, um zukünftige Probleme und andere Überraschungen zu vermeiden. Das gespeicherte Format in der Datenbanktabelle sieht wie folgt aus: ‘JJJJ-MM-tt HH:mm:ss.0’. Zwischen dem Datum und der Uhrzeit steht ein einzelnes Leerzeichen und .0 bezeichnet einen Offset. Dieser Offset beschreibt die Zeitzone. Die mitteleuropäische Standardzeitzone CET hat einen Versatz von einer Stunde. Das bedeutet UTC+01:00 im internationalen Format. Um den Offset separat zu definieren, habe ich gute Ergebnisse mit java.util.TimeZone erzielt, das perfekt mit Date zusammenarbeitet.
Bevor wir fortfahren, zeige ich Ihnen einen kleinen Codeschnipsel in Java für den O/R Manager Hibernate und wie damit die zugehörigen Tabellenspalten erstellt werden können.
Abonnement / Subscription
[English] This content is only available to subscribers.
[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.
Abonnement / Subscription
[English] This content is only available to subscribers.
[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.
Schauen wir uns das obige Listing etwas genauer an. Als erstes sehen wir die @CreationTimestamp Annotation. Das bedeutet, dass beim Erstellen des ArticleDO-Objekts die Variable created mit der aktuellen Zeit initialisiert wird. Dieser Wert sollte sich nie ändern, da ein Artikel nur einmal erstellt, aber mehrmals geändert werden kann. Die Zeitzone wird in einem String gespeichert. Im Konstruktor kann man sehen, wie die System Timezone ausgelesen werden kann – aber Vorsicht, dieser Wert sollte nicht zu sehr vertraut werden. Wenn Sie einen Benutzer wie mich haben, der viel reist, werden Sie sehen, dass ich an allen Orten die gleiche Systemzeit habe, da ich diese normalerweise nie ändere. Als Standardzeitzone definiere ich den richtigen String für UTC-0. Das Gleiche mache ich für die Variable published. Datum kann auch durch einen String erstellt werden, den wir verwenden, um unseren Standard-Nullwert zu setzen. Der Setter für published hat die Möglichkeit, ein zukünftiges Datum zu definieren oder die aktuelle Zeit zu verwenden, falls der Artikel sofort veröffentlicht werden soll. Am Ende des Listings demonstriere ich einen einfachen SQL-Import für einen einzelnen Datensatz.
Aber man sollte nicht zu schnell vorgehen. Wir müssen auch ein wenig darauf achten, wie wir mit dem UTC-Offset umgehen. Denn ich habe in großen Systemen mehrfach Probleme beobachtet, die auftraten, weil Entwickler nur Standardwerte verwendet haben.
Die Zeitzone im Allgemeinen ist Teil des Internationalisierungskonzepts. Um die Zeitverschiebungen korrekt zu verwalten, können wir zwischen verschiedenen Strategien wählen. Wie in so vielen anderen Fällen gibt es kein eindeutiges Richtig oder Falsch. Alles hängt von den Umständen und Notwendigkeiten Ihrer Anwendung ab. Wenn eine Website nur national genutzt wird, wie für ein kleines Unternehmen, und keine zeitkritischen Ereignisse involviert sind, wird alles sehr einfach. In diesem Fall ist es unproblematisch, die Zeitzoneneinstellungen automatisch durch das DBMS zu verwalten. Aber bedenken Sie, dass es auf der Welt Länder wie Mexiko gibt, die mehr als nur eine Zeitzone haben. Bei einem internationalen System, bei dem die Clients über den ganzen Globus verteilt sind, könnte es sinnvoll sein, jedes einzelne DBMS im Cluster auf UTC-0 einzustellen und den Offset durch die Anwendung und die angeschlossenen Clients zu verwalten.
Ein weiteres Problem, das wir lösen müssen, ist die Frage, wie der Datumswert eines einzelnen Datensatzes standardmäßig initialisiert werden soll. Denn Nullwerte sollten vermieden werden. Eine ausführliche Erklärung, warum die Rückgabe von Nullwerten kein guter Programmierstil ist, findet sich in Büchern wie ‘Effective Java’ und ‘Clean Code’. Der Umgang mit Null Pointer Exceptions ist etwas, das ich nicht wirklich brauche. Ein bewährtes Verfahren, das sich für mich bewährt hat, ist die Vorgabe eines Datums- und Zeitwerts durch ‘0000-00-00 00:00:00.0’. Auf diese Weise vermeide ich unerwünschte Veröffentlichungen, und die Bedeutung ist sehr klar – für jeden.
Wie Sie sehen können, gibt es gute Gründe, warum boolesche Datentypen durch Datum ersetzt werden sollten. In diesem kleinen Artikel habe ich gezeigt, wie einfach man mit Datum und Zeitzone in Java und Hibernate umgehen kann. Es sollte auch keine große Sache sein, dieses Beispiel auf andere Programmiersprachen und Frameworks zu übertragen. Wenn Sie eine eigene Lösung haben, können Sie gerne einen Kommentar hinterlassen und diesen Artikel mit Ihren Kollegen und Freunden teilen.
Erste Schritte in Docker mit PostgreSQL

Nach einigen Jahren hat das Virtualisierungstool Docker seine Bedeutung für die Softwarebranche unter Beweis gestellt. Wenn man von Virtualisierung hört, könnte man meinen, dass dies nur etwas für Administratoren ist und mich als Entwickler nicht so stark betrifft. Aber Moment mal. Da könntest du falsch liegen. Denn Grundkenntnisse über Docker können Entwicklern im Alltag helfen.
Schritt 1: Erstellen Sie den Container und initialisieren Sie die Datenbank
docker run -d --name pg-dbms --restart=no \
--ip 172.18.0.20 \
-e POSTGRES_PASSWORD=s3cr3t \
-e PGPASSWORD=s3cr3t \
postgres:11
Wenn Sie möchten, dass PostgreSQL nach einem Neustart immer aktiv ist, ändern Sie die Neustartrichtlinie von „nein“ auf „immer“. Nachdem Sie die Instanz „pg-dbms“ Ihres PostgreSQL 11 Docker-Images erstellt haben, überprüfen Sie, ob der Neustart erfolgreich war. Dies gelingt über den Befehl:
docker ps -a
Schritt 2: Kopieren Sie das initialisierte Datenbankverzeichnis in ein lokales Verzeichnis auf Ihrem Hostsystem
docker cp pg-dbms:/var/lib/postgresql/data /home/user/pg
Das größte Problem mit dem aktuellen Container ist, dass beim Löschen alle Daten verloren gehen. Wir müssen also eine Möglichkeit finden, diese Daten dauerhaft zu speichern. Am einfachsten kopieren Sie das Datenverzeichnis Ihres Containers in ein Verzeichnis auf Ihrem Hostsystem. Der Kopierbefehl benötigt die Parameter „Quelle“ und „Ziel“. Geben Sie als Quelle den Container an, aus dem die Dateien stammen sollen. In unserem Fall heißt der Container „pg-dbms“. Das Ziel ist ein PostgreSQL-Ordner im Home-Verzeichnis des Benutzers „ed“. Unter Windows funktioniert es genauso. Passen Sie einfach den Verzeichnispfad an und vermeiden Sie Leerzeichen. Sobald die Dateien im angegebenen Verzeichnis liegen, ist dieser Schritt abgeschlossen.
Schritt 3: Stoppen Sie den aktuellen Container
docker stop pg-dbms
Wenn Sie einen Container starten möchten, ersetzen Sie einfach „Stop“ durch „Start“. Der Container, den wir zum Abrufen der ursprünglichen Dateien für das PostgreSQL-DBMS erstellt haben, wird nicht mehr benötigt. Wir können ihn löschen. Dazu muss jedoch zunächst der laufende Container gestoppt werden.
Schritt 4: Starten Sie den aktuellen Container
docker start pg-dbms
Nachdem der Container gestoppt wurde, können wir ihn löschen.
Schritt 5: Container mit einem externen Volume neu erstellen
docker run -d --name pg-dbms \
--ip 172.18.0.20 \
-e POSTGRES_PASSWORD=s3cr3t \
-e PGPASSWORD=s3cr3t \
-v /home/user/pg:/var/lib/postgresql/data \
postgres:11
Jetzt können wir das Verzeichnis mit der exportierten ursprünglichen Datenbank mit einem neu erstellten PostgreSQL-Container verknüpfen. Das ist alles. Der große Vorteil dieser Vorgehensweise ist, dass sich nun jede in PostgreSQL erstellte Datenbank und deren Daten außerhalb des Docker-Containers auf unserem lokalen Rechner befinden. Dies ermöglicht eine wesentlich einfachere Sicherung und verhindert Informationsverluste bei Containeraktualisierungen.
Wenn Sie anstelle von PostgreSQL andere Images haben, aus denen Sie Dateien zur Wiederverwendung extrahieren müssen, können Sie dieses Tutorial ebenfalls verwenden. Passen Sie es einfach an das Image und die benötigten Pfade an. Die Vorgehensweise ist nahezu identisch. Wenn Sie mehr über Docker erfahren möchten, können Sie sich auch mein Video „Docker-Grundlagen in weniger als 10 Minuten“ ansehen. Wenn Ihnen dieses kurze Tutorial gefällt, teilen Sie es mit Ihren Freunden und Kollegen. Abonnieren Sie meinen Newsletter, um auf dem Laufenden zu bleiben.