Vorausgeschickt:
Mir sind keine Normen in Bezug auf die Namensgebung für SQL bekannt.
Die folgenden Regeln sind lediglich eine Zusammenfassung der von mir verwendeten Regeln.
Regeln:
Alle Namen von Tabellen und Spalten im Singular.
Alle Namen von Tabellen und Spalten verwenden lediglich a-z (lowercase), 0-9 und _ (underscore).
Namen werden zur besseren Lesbarkeit mit underscore getrennt (z.B. company_address); Tabellen mit Spracherweiterung haben die Extension "_lng"
Namen sollen möglichst klar den Inhalt definieren.
Alle Tabellen- und Feldnamen in Englisch, aber es können spezielle Domain-Namen verwendet werden, wenn dem Verständnis zuträglich, auch wenn nicht in Englisch.
Es gibt reservierte Schlüsselwörte, die immer mit "key" enden und einheitlich in der ganzen Datenbank eingesetzt werden.
"contrykey" wird z.B. als Relation-Key eingesetzt. Key-Felder haben über die verschiedenen Datenbanken hinweg IMMER denselben Wert.
Soe steht der "countrykey" "IT" immer für Italy. "keys" sind normalerweise immer vom Typ "Character varying".
Reservierte Worte: start, end, begin, from => starting, ending
Reservierte Worte: name, description => propname, propdesc
Alle Tabellen haben eine rid (Replikation ID, meist Int64) und einen rts (Zeitstempel, mit exakter Uhrzeit)
Bei JOIN-Tabellen wird in der Kind-Tabelle lower_case_underscore_separated_identifier benutzt (z.B. employee_rid => spalte rid aus der Tabelle employee), wobei "rid" am Ende und NICHT am Anfang gereit wird.
Bezeichner Indexe: Name der aktuellen Tabelle + "-" + Name der Spalte
In PostgreSQL Posts ließt man des öfteren, dass es nicht notwendig ist, für CHARACTER VARYING (und TEXT) Längen-Limits zu setzen, da dies keinen Vorteil bringt.
Längen-Limits können bei Bedarf auch mittels CONSTRAINT realisiert werden. Effektiv sollte laut den diversen Foreneinträgen ein Feld ohne Längen-Limit schneller sein als ein Feld mit Längen-Limit.
TEXT sollte zudem schneller sein als CHARACTER VARYING, weil kein Check ausgeführt werden muss. Aus dem selben Grund sollte CHARACTER nicht benutzt werden.
Bleibt die Frage, wie wartbar die Datenbank ohne klar/schnell ersichtliche Regeln ist, und wie man das versehentliche/gewollte auffüllen der Datenbank verhindert.
Ich nutze trotzdem in den meisten Fällen Regeln und Datenbank Limitierungen ... nicht zuletzt wegen der besseren Wartbarkeit.
Performance-Verlust habe ich meist bei fehlerhaftem Datenbank-Design/Indexes und unpassenden SQL-Befehlen. Mit einem guten Design hat ich noch nie Performance-Probleme.
https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_varchar.28n.29_by_default
Namen für Indexe, Primary key, Foreign key:
Am Beispiel Tabelle "error" mit Feld "code" und Tabelle "error_lng" mit Feld "error_code".
Name Index: error_lng.error_code_ix
Name Primary key: error_lng.error_code_pkey
Name Foreign key: error.error_lng.error_code_fkey
Namen und Funktionsweise von Funktionen:
Von außen aufrufbare Funktionen haben normalerweise immer einen Parameter "jsonin json",
sowie "RETURNS json". Damit ist bereits definiert, dass im Allgemeinen Daten mittels JSON verarbeitet werden.
Das Attribute "language" definiert die Kommunikations-Sprache (z.B. Sprache der Fehlermeldungen) ... nicht jene der Daten.
Jede Function ist wie folgt aufgebaut: modulprefix_name(mit Underscore falls nötig)_get|set|del|chk
Dokumentation Funktionen:
Jede Funktion ist mit einem Kommentar ausgestattet:
/**
* @author: Alex Mutschlechner - teamware
* @created: 2021-..-..
* @description: ... ... ...
* @lastmodified by {name lastname}, {company} - {yyyy-MM-dd}: ...
*/
Hinweis zur Groß- und Kleinschreibung:
SQL-Datenbanken interpretieren die Groß- und Kleinschreibung teilweise unterschiedlich. Da ich mit verschiedenen SQL-Systemen arbeite, verzichte ich daher auf Groß- und Kleinschreibung komplett, um Schwierigkeiten zu vermeiden. PostGreSQL interpretiert meines Wissens Namen/Bezeichner immer als lowercase. Werden Namen/Bezeichner aber in Anführungszeichen gesetzt, werden Groß- und Kleinschreibung beachtet. Andere SQL-DB-Systeme haben wiederum ihre eigenen Regeln.