Mysql Naming Conventions
am 20.09.2005 09:09:09 von punknrollHallo!
Welche Naming Conventions verwendet ihr für Datenbanken?
Ich habe da schon etwas recherchiert. Es gibt das sehr viele
verschiedene Ansätze.
Vielen Dank.
Andi A.
Hallo!
Welche Naming Conventions verwendet ihr für Datenbanken?
Ich habe da schon etwas recherchiert. Es gibt das sehr viele
verschiedene Ansätze.
Vielen Dank.
Andi A.
punknroll schrieb:
> Hallo!
>
> Welche Naming Conventions verwendet ihr für Datenbanken?
Namen sind Schall und Rauch, es kommt darauf an was abgebildet werden soll.
> Ich habe da schon etwas recherchiert. Es gibt das sehr viele
> verschiedene Ansätze.
Wahrscheinlich so viele wie es Datenbanken gibt ;-)
> Vielen Dank.
>
> Andi A.
>
Namen sind Ordnungsschemata, wähl deine Namen doch einfach so das du die
Datenbanken immer wieder sofort zuordnen kannst.
-Kirsten
Krsten schrieb:
> punknroll schrieb:
> > Hallo!
> >
> > Welche Naming Conventions verwendet ihr für Datenbanken?
> Namen sind Schall und Rauch, es kommt darauf an was abgebildet werden sol=
l
> > Ich habe da schon etwas recherchiert. Es gibt das sehr viele
> > verschiedene Ansätze.
> Wahrscheinlich so viele wie es Datenbanken gibt ;-)
> > Vielen Dank.
> >
> > Andi A.
> >
>
> Namen sind Ordnungsschemata, wähl deine Namen doch einfach so das du die
> Datenbanken immer wieder sofort zuordnen kannst.
>
> -Kirsten
also leute es gibt da schon ansätze, warum leute ihre spaltennamen und
ihre indizes nach bestimmten kriterien benennen.
zB.: http://kurafire.net/articles/sql-convention
was haltet ihr von diesem ansatz?=20
andi a.
punknroll wrote:
> also leute es gibt da schon ansätze, warum leute ihre spaltennamen und
> ihre indizes nach bestimmten kriterien benennen.
>
> zB.: http://kurafire.net/articles/sql-convention
>
> was haltet ihr von diesem ansatz?
Was soll das für ein Ansatz sein - die erklären ja nur was sie alles
*nicht* machen. Ich verwende beispielsweise gerne "CamelCase" (nichts
für dich - deine Shift-Taste ist ja hinüber) - die aufgezeigten Probleme
hab ich nicht, weil ich sauber arbeite. So.
Gruß, Gregor
--
Landschafts- und Reisefotografie * http://www.gregorkofler.at
Licht-Blick - Forum für Multivisionsvorträge * http://licht-blick.at
Hi Andi
punknroll wrote:
> Welche Naming Conventions verwendet ihr für Datenbanken?
> Ich habe da schon etwas recherchiert. Es gibt das sehr viele
> verschiedene Ansätze.
Ich halte es wie folgt:
1 Entitäten immer Gross beginnen und in Mehrzahl (Users, Articles, etc)
2 Attribute immer klein beginnen (createdate, firstname, address, etc)
3 Fremdkeys zeigen ja meist auf die ID der anderen Entität (idUsers)
Wenn nicht, befolge ich Regel 2...
Alle Bezeichnungen in der selben Sprache. Bei mir ist Englisch, weil
meine Applikationen auch von anderssprachigen weiter benutzt werden
können müssen.
Über Bezeichnungen von Unique Keys, Indizes u.ä. mache ich mir aber
keine Sorgen, weil ich diese in der (PHP-)Applikation nie benötige.
Mit diesen Grundsätzen habe ich selten Mühe. Und ich muss höchst selten
in der DB wieder nachschlagen, wie nun genau eine Bezeichnung lautet
(User, Users, user, users, benutzer oder womöglich `benützer`).
Wichtig ist: Die Bezeichnung immer so benennen, dass exakt beschrieben
ist, was darin enthalten sein wird.
Das hier stelle ich gerne in Diskussion...
Ich hoffe, das hilft,
Johannes
Johannes Vogel wrote:
> Hi Andi
>
> punknroll wrote:
>
>> Welche Naming Conventions verwendet ihr für Datenbanken?
>> Ich habe da schon etwas recherchiert. Es gibt das sehr viele
>> verschiedene Ansätze.
>
>
> Ich halte es wie folgt:
> 1 Entitäten immer Gross beginnen und in Mehrzahl (Users, Articles, etc)
Ich machs genau anders ;). Entitäten immer in Einzahl (weil eben Entität) (Wie benennst du
Beziehungen?)
> 2 Attribute immer klein beginnen (createdate, firstname, address, etc)
das finde ich ok, wobei ich sowas in der Art createDate und firstName bevorzuge
> 3 Fremdkeys zeigen ja meist auf die ID der anderen Entität (idUsers)
> Wenn nicht, befolge ich Regel 2...
mach ich auch anders, ich benenne die ID dann auch in Users idUsers und auch als
Fremdschlüssel, so kann ich z.B. auch die USING Klausel benutzen
>
> Alle Bezeichnungen in der selben Sprache. Bei mir ist Englisch, weil
> meine Applikationen auch von anderssprachigen weiter benutzt werden
> können müssen.
mach ich auch so
>
> Über Bezeichnungen von Unique Keys, Indizes u.ä. mache ich mir aber
> keine Sorgen, weil ich diese in der (PHP-)Applikation nie benötige.
> Mit diesen Grundsätzen habe ich selten Mühe. Und ich muss höchst selten
> in der DB wieder nachschlagen, wie nun genau eine Bezeichnung lautet
> (User, Users, user, users, benutzer oder womöglich `benützer`).
>
Dafür gibt es Konventionen ja ;)
> Wichtig ist: Die Bezeichnung immer so benennen, dass exakt beschrieben
> ist, was darin enthalten sein wird.
>
> Das hier stelle ich gerne in Diskussion...
getan ;)
> Ich hoffe, das hilft,
> Johannes
Bis denn dann
Stefan
Hi Stefan
Stefan Rybacki wrote:
> Johannes Vogel wrote:
>> punknroll wrote:
>>> Welche Naming Conventions verwendet ihr für Datenbanken?
>>> Ich habe da schon etwas recherchiert. Es gibt das sehr viele
>>> verschiedene Ansätze.
>> Ich halte es wie folgt:
>> 1 Entitäten immer Gross beginnen und in Mehrzahl (Users, Articles, etc)
> Ich machs genau anders ;). Entitäten immer in Einzahl (weil eben
> Entität) (Wie benennst du Beziehungen?)
Beziehungen stellen fast immer auch etwas vernüntiges dar. Wenn ich aber
wirklich nur n:n-Beziehungen habe, nenne ich sie UsersPrivileges. hier
bin ich konform mit Regel 1 - ich hänge die beiden einfach zusammen. :-)
>> 2 Attribute immer klein beginnen (createdate, firstname, address, etc)
> das finde ich ok, wobei ich sowas in der Art createDate und firstName
> bevorzuge
Mach ich auch oft. Meistens aber vor allem dann, wenn ich
Unterscheidungen habe. Gerade bei den Dates: createDate, lastModified
>> 3 Fremdkeys zeigen ja meist auf die ID der anderen Entität (idUsers)
>> Wenn nicht, befolge ich Regel 2...
> mach ich auch anders, ich benenne die ID dann auch in Users idUsers und
> auch als Fremdschlüssel, so kann ich z.B. auch die USING Klausel benutzen
Auf diese verzichte ich gänzlich, weil sie m.E. die Leserlichkeit im
Code nicht gerade verbessern. Bei mir sieht das wie folgt aus:
select A.id, B.name, C.name
from A
join B on A.idB = B.id
join C on A.idC = C.id
>> Über Bezeichnungen von Unique Keys, Indizes u.ä. mache ich mir aber
>> keine Sorgen, weil ich diese in der (PHP-)Applikation nie benötige.
>> Mit diesen Grundsätzen habe ich selten Mühe. Und ich muss höchst
>> selten in der DB wieder nachschlagen, wie nun genau eine Bezeichnung
>> lautet (User, Users, user, users, benutzer oder womöglich `benützer`).
> Dafür gibt es Konventionen ja ;)
Ich kenne Leute, die sich sowas nicht aneignen wollen und dafür um so
mehr Probleme bei der Programmierung haben.
>> Wichtig ist: Die Bezeichnung immer so benennen, dass exakt beschrieben
>> ist, was darin enthalten sein wird.
>> Das hier stelle ich gerne in Diskussion...
> getan ;)
Wunderbar. Ich werde mich trotzdem nicht ändern. :-)
Grüess, Johannes
punknroll schrieb:
> Krsten schrieb:
>
>
>>punknroll schrieb:
>>
>>>Hallo!
>>>
>>>Welche Naming Conventions verwendet ihr für Datenbanken?
>>
>>Namen sind Schall und Rauch, es kommt darauf an was abgebildet werden soll.
>>
>>>Ich habe da schon etwas recherchiert. Es gibt das sehr viele
>>>verschiedene Ansätze.
>>
>>Wahrscheinlich so viele wie es Datenbanken gibt ;-)
>>
>>>Vielen Dank.
>>>
>>>Andi A.
>>>
>>
>>Namen sind Ordnungsschemata, wähl deine Namen doch einfach so das du die
>>Datenbanken immer wieder sofort zuordnen kannst.
>>
>>-Kirsten
>
> also leute es gibt da schon ansätze, warum leute ihre spaltennamen und
> ihre indizes nach bestimmten kriterien benennen.
Klar da haben die auch ihre Gründe für. Wie im Artikel beschrieben.
>
> zB.: http://kurafire.net/articles/sql-convention
>
> was haltet ihr von diesem ansatz?
Ich meine es muß nur eine Konvention aufgestellt werden, wenn man in
einem Projekt mit mehreren arbeitet.
Wenn Du alleine mit der Datenbank arbeitest, ist die einzige Konvention
die mit der Du am besten klar kommst.
Da kannst Du die Haupttabellen auch durchnummerieren und die abhängigen
Tabellen auf zweiter Ebene nummerieren wenn Dir das gefällt oder die
Tabellen Karl, Franz oder Hugo nennen.
>
> andi a.
>
-Kirsten
Hi,
> zB.: http://kurafire.net/articles/sql-convention
>
> was haltet ihr von diesem ansatz?
>
Nicht viel.
"avoid reserved keywords" ist mit einer der wichtigsten Aussagen. Dicht
gefolgt von "underscores are evil". Soviel Sachverstand....
Ich halte es mit den Konventionen ähnlich wie Johannes (Posting gestern
21:48)
1 Entitäten immer Gross beginnen und in Mehrzahl (Users, Articles, etc)
Wenn mehrere Projekte in einer DB liegen (warum auch immer),
kommt vor die Tabelle noch ein Prefix, gefolgt von
evil_underscore (also d125_Users)
Da meine DB-Abstraktionsschicht Prefixes unterstützt, habe ich
damit kein Problem.
2 Attribute immer klein beginnen (createdate, firstname, address, etc)
Jupp. außer primärschlüssel; diese heißen bei mir of
AID, UID usw.
3 Fremdschlüssel heißen wie das Ziel; also auch AID, UID usw.
UID kommt von UserID
AID .. ArticleID
Grüße.
Johannes Vogel wrote:
> Hi Stefan
>...
>
> Wunderbar. Ich werde mich trotzdem nicht ändern. :-)
Das ist völlig in Ordnung, war auch nur als Vergleich gedacht, man hat ja die Wahl ;) Man
muß sich nur dran halten.
Bis denn dsnn
Stefan
>
> Grüess, Johannes
Christoph Becker schrieb:
> 1 Entitäten immer Gross beginnen
Yepp.
> und in Mehrzahl (Users, Articles, etc)
Nope. Ich mappe meistens direkt DB-Datensatz -> Modell-Klasse. Da eine
Instanz der Modellklasse ja nur ein Objekt enthält, benenne ich auch die
Tabellen im Normalfall in Einzahl.
> Wenn mehrere Projekte in einer DB liegen (warum auch immer),
> kommt vor die Tabelle noch ein Prefix, gefolgt von
> evil_underscore (also d125_Users)
> Da meine DB-Abstraktionsschicht Prefixes unterstützt, habe ich
> damit kein Problem.
Und wie siehts bei dieser mit obigem aus?
gruss, heli
Kirsten schrieb:
> Ich meine es muß nur eine Konvention aufgestellt werden, wenn man in
> einem Projekt mit mehreren arbeitet.
> Wenn Du alleine mit der Datenbank arbeitest, ist die einzige Konvention
> die mit der Du am besten klar kommst.
> Da kannst Du die Haupttabellen auch durchnummerieren und die abhängigen
> Tabellen auf zweiter Ebene nummerieren wenn Dir das gefällt oder die
> Tabellen Karl, Franz oder Hugo nennen.
Nunja, man kann sich das Leben ja auch unnötig schwer machen. Warum nicht gleich
einfach ein festes (und vernünftiges) System verwenden und das dann durchgängig,
unabhängig davon, wieviele Entwickler beteiligt sind. Sich bei jedem Projekt
umzugewöhnen geht früher oder später in die Hose. Also lieber gleich richtig,
als sich erst mal einen schlechten Stil für kleine Projekte anzugewöhnen und
später den Ärger haben. (ich hab das Vergnügen, unter anderem eine DB pflegen zu
müssen, bei der das verwendete Schema leider nur zum Teil verwendet wurde. Bei
~50 Tabellen mit zig Spalten macht das keinen Spaß. Aber jetzt die Fehler der
Vorgänger zu korrigieren, ist einfach zu aufwändig. Also muss ich damit leben
und dauernd suchen...)
Martin
Martin Kurz schrieb:
> Kirsten schrieb:
>
> Nunja, man kann sich das Leben ja auch unnötig schwer machen. Warum nicht gleich
> einfach ein festes (und vernünftiges) System verwenden und das dann durchgängig,
> unabhängig davon, wieviele Entwickler beteiligt sind. Sich bei jedem Projekt
> umzugewöhnen geht früher oder später in die Hose. Also lieber gleich richtig,
> als sich erst mal einen schlechten Stil für kleine Projekte anzugewöhnen und
> später den Ärger haben. (ich hab das Vergnügen, unter anderem eine DB pflegen zu
> müssen, bei der das verwendete Schema leider nur zum Teil verwendet wurde. Bei
> ~50 Tabellen mit zig Spalten macht das keinen Spaß. Aber jetzt die Fehler der
> Vorgänger zu korrigieren, ist einfach zu aufwändig. Also muss ich damit leben
> und dauernd suchen...)
>
> Martin
Stimmt schon, ich verwende ja auch selbstsprechende feste Schemata für
die Benennung, allerdings bin ich der Meinung man sollte seinen eigene
Stil entwickeln, zwar kann man sich Inspiration von anderen holen, aber
zu guter letzt muß man sich selbst entwickeln.
Die Grundfrage hörte sich für mich allerdings so an als wollte da jemand
ein vorgekautes Konzept für seine Benennungen haben.
Ich arbeite tagtäglich mit Entwicklern die sich einen solche
Arbeitsmoral angewöhnt haben, immer bei anderen gucken und kopieren und
nie einen eigenen Stil entwickeln. Das Problem dabei ist nur das die
meist gar nicht verstehen was sie da eigentlich tun.
Also Stilkopie ist gut wenn man weiß was man macht und was es bedeutet,
das sehe ich ebenso für Namenskonventionen in Datenbanken.
-Kirsten
Gregor Kofler wrote:
> Ich verwende beispielsweise gerne "CamelCase" (nichts=20
> für dich - deine Shift-Taste ist ja hinüber) - die aufgezeigten Pro=
bleme=20
> hab ich nicht, weil ich sauber arbeite. So.
Auch dieses nicht? ;)
The capital I for id can easily look like a lowercase L
in many fonts, adding to the risk of confusing other people
who have to work with your code.
aber ernsthaft: du scheinst noch nie mit PHP und Oracle gearbeitet
zu haben, sonst wüsstest du das mixed case Namen überhaupt keine
gute Idee sind,
vonDenLesbarkeitsProblemenBeiStudlyCapsNamesMalGanzAbgesehen
--=20
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com