Playing around mit Java und Hibernate

PostgreSQL unter Windows 10

Windows 10 mit Docker Desktop und WSL2 funktioniert einfach super. Man hat die Einfachheit von Windows gepaart mit der Power von Linux. Auf dem Entwicklerrechner habe ich daher:

Gerichteter Graph

Aufgabenstellung war die Speicherung eines gerichteten Graphen inklusive Informationen pro Kante. In SQL schaut es wie folgt aus:

In Hibernate war es aber eine Tüftelei, bis alles funktionierte. Ziel war es, einen Graph in einem „Aufwischer“ zu speichern.

Effizientes Abfragen des Graphen

In der Datenbank wurden viele Graphen gespeichert. Würde man Hibernate die Arbeit machen lassen, würde Hibernate pro Knoten einen Round-Trip machen. Daher wurde zuerst per Common-Table-Expression (CTE) festgestellt, welche Knoten in Frage kommen und anschließend geladen.

Der Aufruf in Java geht relative einfach:

Functions in Spring Data aufrufen

Leider konnte ich - und laut Stackoverflow auch andere User - kein Function mit Array Parameter aufrufen. Spring Data fügt immer eine Klamma ums Array.

Duplikate ohne Primärschlüssel entfernen

PostgreSQL hat selber keine Temporal Tables. Diese historisieren Daten (siehe https://wiki.postgresql.org/wiki/SQL2011Temporal). Nun hat man eine Tabelle ohne Primärschlüssel und idente Rows - was kann man tun? Window-Functions fallen aus. Daher:

Weitere wichtige PostrgreSQL Findings

PostgreSQL hat keinen Ressource Manager wie e.g. in SQL Server den Resource Governor. Allerdings ist das relativ egal, weil man mehrere Instanzen ohne weitere Kosten installieren kann.

Das Suchen nach fehlenden Indizes ist nicht einfach. Man kann durch Statistiken Table Scans sehen. Auch gibt es Tools, welche Log-Files analysieren und Hints geben (pgbadger). Aber so einfach wie in SQL Server geht es leider eben nicht.

Ebenfalls interessant fand ich das Script für die richtige Insert-Reihenfolge.

RDBMS ist tot - lange lebe RDBMS

Interessant ist auch die Entscheidung: NoSQL oder RDBMS. NoSQL ist in aller Munde – daher wird man recht schnell dazu verleitet, sich gegen ein RDBMS zu entscheiden. Doch meine Meinung zu dem Thema ist klar: diese beiden Denkweisen können koexistieren. Beide haben Vor- als auch Nachteile. Oft ist es schwer, das Aggregate – welches man bei NoSQL im Regelfall für die meisten Typen – vor allem Key-Value oder Document – braucht – zu finden. Auch sind Queries, welche die Aggregategrenze überschreiten oft auch nicht trivial. Ja – es gibt dort auch Indizes. Aber referentielle Integrität über Aggregategrenzen hinaus lassen sich in RDBMS leichter abbilden. Hat man aber viele geschlossene Aggregate (die Bestellung, der Kunde, usw.) und beschränken sich die Abfragen auf das Aggregat, ist NoSQL sicher eine super Wahl.