Feldnamen, FeldNamen, feldnamen, feld_namen oder FELDNAMEN?

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
Benutzeravatar
kajarno
User
Beiträge: 26
Registriert: Samstag 16. Januar 2010, 12:41
Wohnort: München
Kontaktdaten:

Zugegebenermaßen ist es eine Geschmackssache, aber es gibt auch guten und schlechten Geschmack. Was wäre also am besten (aus Lesbarkeitssicht, einschließlich Python-Programme) wenn es um die Namensvergebung der Felder geht?

Mein Geschmack sagt mir: Hauptsächlich kleine Buchstaben. Möglicherweise ausschließlich. Aber: Große Anfangsbuchstaben oder nicht? Und bei zusammengesetzten Feldnamen: Große MittBuchstaben, oder lieber trennung_durch_underscore? Es hängt ja auch von der Sprache der Feldnamen ab, wobei Sprachen wie Schwedisch und Deutsch, die die Substantive probemlos aneinanderhaken, eher keine MittBuchstaben brauchen, dahingegen braucht Englisch die MiddleCaps schon eher.

Eine andere Überlegung: Sollte ich Feldnamen irgendwie daran erkennen, dass die im Gegensatz zu Variabelnamen immer klein anfangen?

Viele Fragen! Was ist am deutlichsten (und damit auf Dauer am effektivsten)?

Ich finde A (FeldNamen) am deutlichsten
+ KajText, Kajtext und kajtext werden zudem alle verstanden (= SchreibvaRiaTionen werden richtig interpretiert) da die wenigsten Datenbanksysteme auf Feldebene Case Sensitive sind

Ich finde B (Feldnamen) auch OK aber längere Feldnamen wie pairautoincr werden unleserlich

Ich finde C (feldnamen) kennzeichnet vielleicht Felder als Felder (und keine Variablen), und habe ich bisher lange benutzt, aber längere Feldnamen wie pairautoincr werden unleserlich

Ich finde D (feld_namen) zwar leserlich aber insofern schlecht, als das ich mich schnell zwischen pair_auto_incr und pair_autoincr vertippe

Ich finde das schreiende E (FELDNAMEN) gehört zu VERGANGENEN JAHRZEHNTEN

Sonstige Ansichten? Habe ich etwas übersehen?

A: FeldNamen

Code: Alles auswählen

CREATE TABLE kajbookrow (
 Entity char(10) NOT NULL,
 Period char(5) NOT NULL,
 KajDate date NOT NULL,
 AutoIncr int NOT NULL AUTO_INCREMENT,
 PairAutoIncr int,
 Account smallint, 
 PairAccount smallint,
 Amount decimal(9,2),
 KajText varchar(50), 
 Keyword varchar(10),
 PRIMARY KEY (Entity, Period, Kajdate, AutoIncr));
B: Feldnamen

Code: Alles auswählen

CREATE TABLE kajbookrow (
 Entity char(10) NOT NULL,
 Period char(5) NOT NULL,
 Kajdate date NOT NULL,
 Autoincr int NOT NULL AUTO_INCREMENT,
 Pairautoincr int,
 Account smallint, 
 Pairaccount smallint,
 Amount decimal(9,2),
 Kajtext varchar(50), 
 Keyword varchar(10),
 PRIMARY KEY (Entity, Period, Kajdate, Autoincr));
C: feldnamen

Code: Alles auswählen

CREATE TABLE kajbookrow (
 entity char(10) NOT NULL,
 period char(5) NOT NULL,
 kajdate date NOT NULL,
 autoincr int NOT NULL AUTO_INCREMENT,
 pairautoincr int,
 account smallint, 
 pairaccount smallint,
 amount decimal(9,2),
 kajtext varchar(50), 
 keyword varchar(10),
 PRIMARY KEY (entity, period, kajdate, autoincr));
D: feld_namen

Code: Alles auswählen

CREATE TABLE kajbookrow (
 entity char(10) NOT NULL,
 period char(5) NOT NULL,
 kaj_date date NOT NULL,
 auto_incr int NOT NULL AUTO_INCREMENT,
 pair_auto_incr int,
 account smallint, 
 pair_account smallint,
 amount decimal(9,2),
 kaj_text varchar(50), 
 keyword varchar(10),
 PRIMARY KEY (entity, period, kajdate, autoincr));
E: FELDNAMEN

Code: Alles auswählen

CREATE TABLE kajbookrow (
 ENTITY char(10) NOT NULL,
 PERIOD char(5) NOT NULL,
 KAJDATE date NOT NULL,
 AUTOINCR int NOT NULL AUTO_INCREMENT,
 PAIRAUTOINCR int,
 ACCOUNT smallint, 
 PAIRACCOUNT smallint,
 AMOUNT decimal(9,2),
 KAJTEXT varchar(50), 
 KEYWORD varchar(10),
 PRIMARY KEY (ENTITY, PERIOD, KAJDATE, AUTOINCR));
Kaj Arnö, Sun VP MySQL Community Relations
Vormals (1979-99) Programmierer, möchte 2010 alte Künste wiederbeleben, und zwar mit PyObjC und MySQLdb unter Mac. Aus Finnland, Muttersprache Schwedisch. Bevorzugt Deutsch über Englisch. In München seit 2006.
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

Hallo.

In den seltenen Fällen, in denen ich mal SQL benutze, schreibe ich Namen vollständig in Kleinbuchstaben, reservierte vollständig in Großbuchstaben. In beiden Fällen trenne ich durch Unterstriche. Das hat sich für mich irgendwie am übersichtlichsten rausgestellt.

Sebastian
Das Leben ist wie ein Tennisball.
Benutzeravatar
kajarno
User
Beiträge: 26
Registriert: Samstag 16. Januar 2010, 12:41
Wohnort: München
Kontaktdaten:

Danke Sebastian!
EyDu hat geschrieben:Hallo.

In den seltenen Fällen, in denen ich mal SQL benutze, schreibe ich Namen vollständig in Kleinbuchstaben, reservierte vollständig in Großbuchstaben. In beiden Fällen trenne ich durch Unterstriche. Das hat sich für mich irgendwie am übersichtlichsten rausgestellt.

Sebastian
Kaj Arnö, Sun VP MySQL Community Relations
Vormals (1979-99) Programmierer, möchte 2010 alte Künste wiederbeleben, und zwar mit PyObjC und MySQLdb unter Mac. Aus Finnland, Muttersprache Schwedisch. Bevorzugt Deutsch über Englisch. In München seit 2006.
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Du hast feldNamen vergessen ;)

*SCNR*
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Ich schreib kein SQL in Python Anwendungen.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Hallo kajarno!

Ich verwende Variante D (datenbankübergreifend).

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Zap
User
Beiträge: 533
Registriert: Freitag 13. Oktober 2006, 10:56

Ich verwende ebenfalls Variante D.

Ein technischer Aspekt: Zumindest bei PostgreSQL ist man gezwungen Feld- und Tablenamen zu quoten wenn sie nicht komplett lowercase geschrieben sind.
Benutzeravatar
Käptn Haddock
User
Beiträge: 169
Registriert: Freitag 24. März 2006, 14:27

Zap hat geschrieben:Ich verwende ebenfalls Variante D.

Ein technischer Aspekt: Zumindest bei PostgreSQL ist man gezwungen Feld- und Tablenamen zu quoten wenn sie nicht komplett lowercase geschrieben sind.
Genau deswegen verwende ich auch auschliesslich D. MAnchmal auch alles klein, dann kann ich sehen, was ich schreibe und was die DB schreibt. Quotes stören mich und es ist was wo man ständig drandenken muß :)

CU Uwe
---------------------------------
have a lot of fun!
Benutzeravatar
kajarno
User
Beiträge: 26
Registriert: Samstag 16. Januar 2010, 12:41
Wohnort: München
Kontaktdaten:

Alles sehr interessante Aspekte! Das mit den Quotes von PostgreSQL hatte ich noch nicht gehört. Da würde ich auch unbedingt D wählen.
Käptn Haddock hat geschrieben:
Zap hat geschrieben:Ich verwende ebenfalls Variante D.

Ein technischer Aspekt: Zumindest bei PostgreSQL ist man gezwungen Feld- und Tablenamen zu quoten wenn sie nicht komplett lowercase geschrieben sind.
Genau deswegen verwende ich auch auschliesslich D. MAnchmal auch alles klein, dann kann ich sehen, was ich schreibe und was die DB schreibt. Quotes stören mich und es ist was wo man ständig drandenken muß :)

CU Uwe
Kaj Arnö, Sun VP MySQL Community Relations
Vormals (1979-99) Programmierer, möchte 2010 alte Künste wiederbeleben, und zwar mit PyObjC und MySQLdb unter Mac. Aus Finnland, Muttersprache Schwedisch. Bevorzugt Deutsch über Englisch. In München seit 2006.
Antworten