Konventionen für Tabellennamen

[Eddie]

Hallo allerseits,

mich würde mal interessieren, wie ihr eure Tabellen benennt? Klar, erstmal im Singular, aber sonst hat man ja doch viel Freiheit!

SCHREIBWEISE:
Nutzt ihr nur Kleinschreibung, und wenn ja mit irgendwelchen Trennzeichen (z.B. "my_table")?

M:N-RELATIONEN:
Wie bennennt ihr m:n-Zuordnungen? Ich mache das bisher häufig so: "rel_client_town", damit sehe ich auf einen Blick, dass dort keine wirklichen Daten drinstehen. Aber ob das ideal ist?

STATISCHE/DYNAMISCHE INHALTE:
Habt ihr eine Konvention für Tabellen, die fast nie (oder aber ständig) Änderungen erfahren? Z.B. "static_mathConstants" oder "dyn_mathResults"...

STATISCHE WERTE MIT FESTER TABELLENGRÖSSE:
Z.B. lagere ich ENUM-Werte bei MySQL oft aus, bspw. in eine Tabelle "geoType" mit den Zeilen "Stadt", "Land" und "Fluss". In der Tabelle "Orte" steht dann ein entsprechender Fremdschlüssel.
Wie bennent ihr solche Tabellen? Sind bei mir grad sehr viele, also haette ich da gerne eine Konvention!

Freu mich schon auf die Diskussion!

Eddie

[King^Lully]

mich würde mal interessieren, wie ihr eure Tabellen benennt? Klar, erstmal im Singular, aber sonst hat man ja doch viel Freiheit!

Singular??
Es handelt sich doch immer um Mitarbeiter, Verträge, Anfragen, Adressen etc..

SCHREIBWEISE:
Nutzt ihr nur Kleinschreibung, und wenn ja mit irgendwelchen Trennzeichen (z.B. "my_table")?

Grossschreibung des ersten Buchstabens, der deutschen Kultur geschuldet, auch auf englisch.   ;)

M:N-RELATIONEN:
Wie bennennt ihr m:n-Zuordnungen? Ich mache das bisher häufig so: "rel_client_town", damit sehe ich auf einen Blick, dass dort keine wirklichen Daten drinstehen. Aber ob das ideal ist?

Wenn bspw. eine "n:m" zwischen Hunde und Menschen gegeben ist, dann heisst die "n:m" "Hunde_Menschen".

STATISCHE/DYNAMISCHE INHALTE:
Habt ihr eine Konvention für Tabellen, die fast nie (oder aber ständig) Änderungen erfahren? Z.B. "static_mathConstants" oder "dyn_mathResults"...

Das haben Wir nicht, was ist die Idee dahinter?

STATISCHE WERTE MIT FESTER TABELLENGRÖSSE:
Z.B. lagere ich ENUM-Werte bei MySQL oft aus, bspw. in eine Tabelle "geoType" mit den Zeilen "Stadt", "Land" und "Fluss". In der Tabelle "Orte" steht dann ein entsprechender Fremdschlüssel.
Wie bennent ihr solche Tabellen? Sind bei mir grad sehr viele, also haette ich da gerne eine Konvention!

Mal erläutern...

[Eddie]

mich würde mal interessieren, wie ihr eure Tabellen benennt? Klar, erstmal im Singular, aber sonst hat man ja doch viel Freiheit!

Singular??
Es handelt sich doch immer um Mitarbeiter, Verträge, Anfragen, Adressen etc..

Versuch mal aus der Tabelle "contracts" automatisch Methoden zu generieren (z.B. mit Propel)! Dann endest du mit zwei Methoden

• getContracts(id) ==> Verwirrung
• getContractss()  ==> Doppelt gemoppelt
  U.a. darum ist das Konvention!

Bei allen anderen Fragen wollte ich nur mal eure Meinung und Erfahrungen hinterfragen, meines Wissens gibt's da naemlich keine Konvention...

Eddie

[King^Lully]

Versuch mal aus der Tabelle "contracts" automatisch Methoden zu generieren (z.B. mit Propel)! Dann endest du mit zwei Methoden

• getContracts(id) ==> Verwirrung
• getContractss()  ==> Doppelt gemoppelt
  U.a. darum ist das Konvention!

Am Singular haben sich schon Generationen von Entwicklern ein Problem gerubbelt, Wir verzichten auf ihn. "GetContractss" würde bei uns "LST_Contracts" heissen. Du kennst ja das Problem, dass bei einigen Wörtern Singular und Plural identisch sind. *Würg*

Bei allen anderen Fragen wollte ich nur mal eure Meinung und Erfahrungen hinterfragen, meines Wissens gibt's da naemlich keine Konvention...

Tom hat weiter obe noch was Schlaues geschrieben: Namen sollen keine Strukturen nachbilden. Das ist das einzige Gegenargument, das Wir anerkennen gegen die King^Lully Notation für Datenfelder:
<Tabellenname als Präfix>_<Datenfeldname> ("_" + ggf Suffix wie "ID" oder "UFID" oder "GUID")
Haben auch weiter unten im Forum noch was dazu geschrieben...

[Tom]

Hello Eddie,

Du wirst Dir denken können, dass ich mir darüber schon viele Gedanken gemacht habe.
Da ich im Web mit solch minimalistischen Systemen, wie MySQL 3.x angefangen habe, habe ich versucht, auch meine Nomenklatur einigermaßen wiedererkennbar zu halten.

Eigentlich sollte man in Namen ja keinerlei Struktur hineinlegen, aber wenn es die Tabellensysteme eben nicht leisten, dann bleibt einem oft nichts anderes übrig.

Der erste Schritt war damals die Bennenung der Schlüsselwerte

ID_tabellenname      stand an erster Stelle für den Primaray Index
ID_tabellenname      an späterer Stelle stannd für einen Fremdschlüssel
                     oder wenn 'tabellenname' identisch war, für einen Selbstbezug
usw usw

Irgendwann habe ich dann erkannt, dass man das nur benötigt, wenn das DBMS noch nicht erwachsen ist

Wenn es wenigstens die Mitwirkung unterstützen wollte, dann würde es pro Database und pro tabelle einen umfangreichen frei belegbaren Description-Bereich zulassen, der billig[1] abfragbar wäre. Das wäre dann die Vorstufe zu "stored Procedures".

Jedenfalls konnte ich 1988 mit bTrieve (ohne SQL-Schnittstelle, die gab es extra) schon mehr bewegen, als später mit den "neuen SQL-Datenbanken" ...

Das Problem an den SQL-Datenbanksystemen ist, dass sie nicht offen sind für Anprogrammierungen.
Das System müsste sich quasi weigern, eine Antwort zu geben, wenn anprogrammierte Funktionen der API eingetragen sind, und diese beim Request nicht erkannt werden können.

Schichten zu bilden, ist intelligent --> Schnittstellen
schichtenverbindede Kommunikation vorzusehen ist intelligenter --> Verbindungsstellen

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom