Ist sonst noch jemandem der Unterschied zwischen Datenbankdesign und Softwaredesign aufgefallen? Ich fürchte viele Leser fragen sich gerade: "Wovon redet er jetzt nun wieder?", also einen Tipp: Schaut euch einfach den Inhalt der ersten paar Suchergebnisse bei Google zu den beiden Themen an.

Nichts aufgefallen?

Na gut, ich helfe. Bei Datenbank Design geht es um so Dinge wie: Welchen Datentyp sollten die Primary Keys haben? Verwendet man lieber Surrogate oder Composite Keys? Welche Spalten sollte man auf welche Weise indizieren?

Bei Software Design geht es früher oder später um Modularität, Unabhängigkeit, Low Coupling and High Cohesion und ähnliche Konzepte. Da ist es kein Wunder, dass kaum jemand, der sich einmal ernsthaft mit Software Design beschäftigt hat, sich noch mit Datenbankdesign beschäftigen möchte. Erfahrene Datenbankdesigner schlagen sich mit den Problemen herum die der Frage entsprechen, ob man lieber eine HashMap oder eine TreeMap verwendet. Das ist nicht spannend.

Da stellt sich natürlich erstmal die Frage: Warum ist das so? Es liegt sicherlich in der Natur von Datenbanken persistent zu sein, um nicht zu sagen pertinent, 'tschuldigung, ich meine natürlich statisch. Schon allein die Idee an der Struktur einer Datenbank etwas zu ändern scheint DBAs zu erschrecken. Aber die Frage ist durchaus berechtigt:

Wieso sollte man in einer Anwendung Teile der Datenbank austauschen? Im normalen Betrieb gibt es dafür natürlich wenig Gründe, aber wenn die Anwendung, die auf die Datenbank aufsetzt, modular strukturiert ist, wieso sollte dann das Datenbank Schema wie ein großer Blob, ein Monolith, ein Eisenkugel samt Fußfessel daher kommen?

Wunderbar, wir haben also festgestellt, das Datenbankdesign dem Stand der Technik etwa 30 Jahre hinterherhinkt, und dass dies schlecht ist. Diese Erkenntnis ist nicht wirklich neu, sonst hätte sich im Datenbankumfeld ja herumgesprochen, wie man refactort ... refactoriesiert ... na seinen Code so umbaut, dass er nachher 'sauberer' ist. Womit wir an einer interessanten Stelle gelandet sind.

Ein Grund warum refactoren bei Datenbanken so extrem schwierig ist, ist das häufig Hinz und Kunz und ihre Schwestern auf dieDatenbank zugreifen. Man kann also nicht einfach eine Tabelle umstrukturieren, weil dann garantiert eine von Myriaden nicht näher spezifizierten Schnittstellen aufs Gesicht fällt. Alle Datenbankentwickler und Administratoren bitte einmal herhören: So etwas tut man nicht! Schnittstellen auch wenn sie in Form von Tabellen existieren, gehören sauber getrennt vom Rest des Systems. Tut euch einen Gefallen, wenn ein anderes System als das eigene auf die eigene Datenbank zugreifen soll, geht es über eine entsprechende Schnittstelle. Es ist egal ob dies ein Satz Views ist, Stored Procedures oder eine Java API. Diese sollten direkt als Schnittstelle erkennbar sein, zum Beispiel in dem sie mit einem entsprechenden Prefix versehen werden (mein persönlicher Vorschla: IF_ für alle beteiligten Datenbankartefakte), oder noch besser in einem eigenen Schema liegen.

Mehr Ideen, wie man ein Datenbank Schema modular gestalten kanns  garen in meinem Kopf ... vielleicht bis einem zukünftigem Post.