Denkt man an eine Datenbank mit mehreren Datenlieferanten und -abnehmern (darunter in der Regel Applikationen und Schnittstellen von und zu weiteren Datenbanken), so ist leicht vorstellbar, dass Objekte nicht einfach umbenannt werden können. Es sollten also von Anfang an die passenden Namen vergeben werden.
Verglichen mit der Benennung von Klassen in objektorientierten Programmiersprachen, hat der Datenbankentwickler zudem mit der beschränkten Hierarchie von Namensräumen zu kämpfen. Während Oracle nur das Schema für alle Objekttypen und für PL/SQL-Code zusätzlich die Packages kennt, kann in Java eine frei benennbare Hierarchie von Java-Packages aufgespannt werden, in der Klassen eingeordnet werden können.
Ebenso kann die Länge eines Bezeichners eingeschränkt sein. Glücklicherweise wird mit Oracle 12cR2 die Beschränkung von 30 Byte für einen Bezeichner auf 128 Byte angehoben.
Wahl von passenden Namen
Bei der Wahl von Namen sollte stets der fachliche Bezug berücksichtigt werden. In der Regel wird sich der fachliche Bezug in den Namen der Relationen (Tabellennamen) widerspiegeln.
Nicht zuletzt aufgrund der Längenbeschränkung für Bezeichner empfiehlt es sich, ein menschenlesbares Kürzel (also ein mnemonic) für jede Tabelle einzuführen.
Einer Tabelle zugeordnet sind z.B. Trigger, Indexe, Sequenzen oder Constraints. Deren Benennung sollte gewissen Regeln folgen. Die Zugehörigkeit eines solchen Objekts zu einer Tabelle sollte ersichtlich sein; ebenso wie der Objekt-Typ und damit letztlich die technische Ausführung.
Beispiel:
Alle Beschäftigen sind in der Tabelle employee enthalten (Fachlicher Bezug).
Die Tabelle employee erhält das Kürzel emp.
Es existiert eine Sequenz mit dem Namen emp_seq.
Es existiert ein Trigger mit dem Namen emp_seq_tg
Anhand unserer Namenskonventionen wissen wir nun Folgendes:
- Die Sequenz
emp_seqgehört, ebenso wie der Triggeremp_seq_tg, zur Tabelleemployee, da diese das Kürzelempträgt. - Da die Sequenz einen Namen gemäß unserer Konvention trägt:
- wird aus der Sequenz die technische Schlüsselspalte
employee.idbefüllt - beginnt die Sequenz bei 1 und endet bei 1018-1, passt somit, ebenso wie
employee.id, in einem 64bit Integer - Die Sequenz wiederholt sich nicht.
- wird aus der Sequenz die technische Schlüsselspalte
- Da ebenso der Trigger einen Namen gemäß unserer Konventionen trägt, wissen wir, dass:
- Dieser Trigger befüllt die technische Schlüsselspalte
employee.id - Der Trigger tut nichts anderes. (Das ist gut!)
- Dieser Trigger befüllt die technische Schlüsselspalte
Das ist schon eine Menge implizites Wissen, welches durch die Namenskonventionen transportiert wird. In unsere Namenskonventionen haben wir auch ein paar „Best Practices“ einfließen lassen, so z.B. der weitgehende Verzicht auf Trigger und die Datentypen für Sequenzen und id-Spalten.
Namenskonventionen müssen lebendig sein
Wir haben uns entschieden, unsere Namenskonventionen unter Open Source Lizenz öffentlich zu machen und wollen diese auch öffentlich diskutieren. Diese sind hier zu finden:
https://github.com/triologygmbh/database-conventions/blob/master/i18n/README.de.md
Die in diesem Artikel beschriebenen Konventionen befinden sich dort und enthalten noch weitere Konventionen im Detail.
