Es gibt wohl kaum ein Thema, dass im Datenbankumfeld so umstritten ist, wie ein konkretes Schema für die Benennung von Objekten in Datenbanken.

Es gibt nicht nur keinen Standard, selbst so etwas wie eine einfache Konvention scheint ob der völlig konträren Positionen der Diskussionsteilnehmer völlig unmöglich zu sein.

Aus diesem Grund soll die folgende Liste von Stichpunkten auch keinerlei Anspruch auf die objektive Wahrheit erheben, sondern lediglich das wiedergeben, was sich in zahlreichen Projekten von mir als sinnvoll erwiesen hat.

• kein Abweichen von der ersten Normalform – d.h. niemals strukturierte Daten in einzelnen Datenbankfeldern
• so normalisiert wie möglich (insbesondere niemals Daten redundant speichern) – nur in Ausnahmefällen denormalisiert lassen (z.B. Anrede “Herr/Frau” nicht in separate Tabelle auslagern)
• grundsätzlich alle Bezeichner in Kleinbuchstaben; Unterstriche sind erlaubt (“person” statt “Person”)
• grundsätzlich alle Bezeichner in der gleichen Sprache
• Tabellen und Attributnamen im Singular (“person” statt “personen”)
• Attributnamen (außer Fremdschlüssel) mit Präfix, der Kurzform des Tabellennamens wiederspiegelt (“pers_name” statt “name”)
• Primärschlüssel ist immer eine separate Spalte namens Präfix + “_id” (“pers_id”) vom Typ Serial (PostgreSQL) bzw. Integer Auto Increment (MySQL)
• Fremdschlüsselnamen werden inklusive Präfix von der referenzierten Tabelle übernommen (“pers_id” bleibt in jeder referenzierenden Tabelle “pers_id”)
• keine Abkürzungen (“pers_geburtsjahr” statt “pers_geb”)
• keine “Anreicherung” von Attributnamen (“pers_geburtsjahr” statt “pers_geburtsjahr_int”)
• Spalten mit Booleschen Werte so benennen, dass sofort klar ist, wofür true/false stehen (“maennlich” statt “geschlecht”)

Diese Liste ist zwar offensichtlich unvollständig, aber selbst diese minimale Konvention hat mir schon sehr gute Dienste, vor allem bei der Erklärung der Datenbankschemata gegenüber Dritten, geleistet.