nicht angemeldet
SQL "Codingstandard"
Hallo zusammen,
gerade wurde ich durch EKKi (User hier aus dem Forum) mit dem Thema Normalisierung konfrontiert, was mich auf eine weitere Frage gebracht hat zu der ich "der Ordnung halber" ein neues Thema aufmachen möchte.
Und zwar: Gibt es einen "Codingstandard" für SQL Tabellen?
Z.B.: Für die Namen der Tabellen?
prefix_tabelle1
prefix_typen
Ab wann verknüft man Tabellennamen?
prefix_tabelle1
prefix_tabelle1_typen
Oder wie baut man die Primary KEYs für die Tabellen richtig?
id
id_tabellenname
tabellennamen_id
Underscroes zur Trennung der Tabellennamen, macht das Sinn?
Verwendet man einen Underscore oder macht ein CamelCase bei MySQL Tabellen Sinn?
Ich würde mich freuen wenn dazu jemand ein wenig Info für mich hat.
Danke und Viele Grüße
Chrisi
-
Hallo,
Und zwar: Gibt es einen "Codingstandard" für SQL
sehr üblich ist es, SQL-Schlüsselwörter, Funktionen, ... konsequent groß und Identifier wie Tabellennamen, Spaltennamen, ... konsequent klein zu schreiben.
Verwendet man einen Underscore oder macht ein CamelCase bei MySQL Tabellen Sinn?
Infolgedessen kommt CamelCase für Tabellennamen nicht in Frage. Da ellenlange Namen auch nicht besonders lesbar sind, kann man zum Beispiel Underscores verwenden.
Tabellen?
Z.B.: Für die Namen der Tabellen?prefix_tabelle1
prefix_typenPräfixe sind Geschmackssache und somit eine Frage, was im Projekt festgelegt ist. Mein Geschmack sind sie nicht. Was Du mit prefix_typen meinst, ist mir nicht klar.
Ab wann verknüft man Tabellennamen?
keine Ahnung, was Du damit meinst.
Grundsätzlich bist Du in den meisten SQL-Dialekten sehr frei, was die Namen von Identifiern angeht, solange Du diese ordentlich quotest. Wenn ANSI-Quotes aktiviert sind (was sehr viele DBMS beherrschen), dann ist das doppelte Anführungszeichen zum Quoten zu verwenden - wenn nicht, dann das, was das DBMS vorsieht.
Weiterhin ist es eine sehr gute Idee, Zeichenketten in einfache Anführungszeichen zu packen, weil dies so ziemlich jeder SQL-Dialekt versteht. Doppelte Anführungszeichen versteht hingegen kaum ein DBMS. Mir fällt nur MySQL ein, wenn ANSI-Quotes *nicht* aktiviert sind.
Eines kann man sich abschminken: zu glauben, man könne portables SQL schreiben.
Freundliche Grüße
Vinzenz
-
Moin Moin!
Eines kann man sich abschminken: zu glauben, man könne portables SQL schreiben.
Man kann, wenn man nicht alles in SQL lösen muß, mit einheitlichen SQL-Statements recht weit kommen.
Eines meiner alten Projekte konnte Oracle, MS SQL Server und PostgreSQL in fast allen Fällen mit dem selben SQL-Statement benutzen. Einzig für INSERTs mit automatisch vergebenen IDs war etwas Extra-Arbeit nötig, den hat aber ein sehr dünner Layer über DBI erledigt. Eine große Hilfe ist natürlich auch DBI selbst, das für einheitliche Schnittstellen zu den verschiedenen Datenbanken sorgt.
Man muß sich das Portieren ja auch nicht unnötig schwer machen, indem man alle propritären Extras der jeweiligen Datenbank ausreizt. Dazu gehört z.B., dass man Identifier bei MySQL eben nicht mit Backticks quotet. Datumsfunktionen sind auch nicht eben schick, ich hab mich in dem Projekt dadurch herausgewieselt, dass die Datenbank nur einen großen Integer der Unix-Zeit gespeichert hat, und die ganze Umwandlung von und nach Datum/Uhrzeit in der Anwendung stattfand.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". -
Hi
Verwendet man einen Underscore oder macht ein CamelCase bei MySQL Tabellen Sinn?
... Infolgedessen kommt CamelCase für Tabellennamen nicht in Frage.
Das kann ich jetzt subjektiv nicht ganz nachvollziehen. Aber meintest du jetzt "UpperCamelCase" oder "PascalCase" oder "camelCase"?
Da ellenlange Namen auch nicht besonders lesbar sind, kann man zum Beispiel Underscores verwenden.
Gott-sei-dank hat Mickeysoft ein Limit von 128 Zeichen für "sysname" ;-)
An den Original-Fragen-Steller:
Meine ganz persönliche Meinung zu dem Thema: Verwende, was
a) übersichtlich / lesbar bleibt, im mindesten für dich
b) was sich am schnellsten tippen lässt (man muss die Limite für Objekt-/Variablennamen nicht immer ausreizen)
Und sei einfach konsequent durch den ganzen Code hindurch.Aber sich da lange den Kopf drüber zerbrechen, das kannst du Avanade / Accenture Consultants überlassen, damit erweitern die mal ihren technischen Horizont. (Ausnahmen bestätigen die Regel!).
Cheers, Frank
-
moin,
z»» Gott-sei-dank hat Mickeysoft ein Limit von 128 Zeichen für "sysname" ;-)
es macht wenig sinn, von seiten des dbms die länge von objektnamen zu begrenzen. sicherlich muss es eine technische grenze geben, aber keine fachliche. oracle erlaubt nur 30 zeichen, sprich ms sql bietet da wesentlich mehr und das ist gut so. ich hatte lange diskussionen in der oracle community über das thema. für mich kann nur einer die größe des objektnamen festlegen, nämlich die benutzer des dbms. die möglilchkeit sehr lange objektennamen zu verwenden bedeutet nicht, dass man es auch immer tut. namen sollten sinnvoll gewählt sein. so kurz wie möglich, aber so lang wie nötig, damit sie sprechend bleiben.
Ilja
-
-
-
moin,
so wie Vinzenz schon sagte, vieles ist geschmackssache, bzw. auf firmeninterne richtlinien zurück zu führen.
Z.B.: Für die Namen der Tabellen?
wir benutzen zurzeit keine präfixe für tabellennamen, aber für spalten, denen dann eine besondere bedeutung zukommt und scripte sich darauf beziehen können. wir schreiben die namen der objekte und attributn in englisch und benutzen die camel-schreibweise. es ist sicherlicha auch immer eine frage der gewöhnung. ich finde es wesentlich besser als ein underscore zeichen zu benutzen.
Oder wie baut man die Primary KEYs für die Tabellen richtig?
es gibt kein richtig, man mus sich auf einen standard einigen. das kann auch von umgebung zu umgebung ganz unterschiedlich sein. wir prefixen zum beispiel den primary key, foreign keys, unique spalten, etc. ich finde das prinzip sehr gut, weil ich nur über das grafische design sehr viele informationen herausbekommen kann, ohne auf metadaten der datenbank zugreifen zu müssen.
Underscroes zur Trennung der Tabellennamen, macht das Sinn?
bei Tabellennamen für mich nicht, wie gesagt da benutze ich lieber die camel-schriebweis, weil ich mir einfach jeweils ein zeichen spare und es immer noch übersichtlich aussieht. ich benutze das underscore wenn ich objektnamen wie foreign keys vergebe, welche die tabellennamen voneinander trennt oder bei constraintnamen.
Ilja
-
Präfixe für Tabellen oder Spalten halte ich für Unsinn, denn die Position eines Bezeichners in einem Statement lässt keine Zweifel offen, um was es sich da gerade handelt.
Oder wie baut man die Primary KEYs für die Tabellen richtig?
Zum Beispiel wäre pid für eine PersonalID eine gute Idee. Die Tabelle ausschreiben halte ich für lästig. Nur id verwenden ist wieder schlecht wenn du eine Referenz in einer anderen Tabelle auf das Feld machst.
-
moin,
Präfixe für Tabellen oder Spalten halte ich für Unsinn, denn die Position eines Bezeichners in einem Statement lässt keine Zweifel offen, um was es sich da gerade handelt.
es geht nicht um abfragen, bei der bennung von objekten und attributen, ganz im gegenteil. gerade dort ist es unerheblich, weil man alias namen oder views verwenden kann. und es macht sehr viel sinn, gut ausgewählte namen zu vergeben. das können auch präfixe sein, wenn es einen mehrgewinn darstellt.
Zum Beispiel wäre pid für eine PersonalID eine gute Idee. Die Tabelle ausschreiben halte ich für lästig.
das sehe ich ebenfalls anders, pid sagt mir mal gar nichts, weil ich es nicht eindeutig einer tabelle zuordnen kann. und die meisten tools bieten heute eine autovervollständigung, das macht das leben leichter.
Ilja
-
das können auch präfixe sein, wenn es einen mehrgewinn darstellt.
Klar, wenn das so ist schon. Nur sind Präfixe oft nur reine Gewohnheit. Die Buchstaben verwende ich lieber für einen aussagekräftigeren Namen an sich. Da spare ich dann auch nicht. Und davon habe ich oft letztendlich mehr.
das sehe ich ebenfalls anders, pid sagt mir mal gar nichts, weil ich es nicht eindeutig einer tabelle zuordnen kann. und die meisten tools bieten heute eine autovervollständigung, das macht das leben leichter.
Besser als nur id meinte ich. Man kann ja auch persid oder personalID oder sowas nehmen. Ich wollte damit sagen, ich würde mich nicht drauf versteifen immer tabellenname_id zu nehmen.
-
-