7
Best Practice: Feldname für Datensatzbezeichner bzw. Primärindex
Moin in die Runde,
Ich bin gerade dabei eine Datenbank neu zu strukturieren und zu konsolidieren, um einiges an "Altlasten" rauszubekommen und diese für neue Anforderungen umzustellen und vorzubereiten
Dabei bin ich wiedereinmal darüber gestolpert, daß in der derzeitegen DB. nahezu alle Primärschlüssel den Feldnamen "Nr" oder "Auto_ID" haben (als autoincrement).
Kurze und knappe Frage:
Gibt es eigentlich sowas wie eine Empfehlung für die Benennung der Feldnamen von Datensatzbezeichnern / Primärinexen?
Ist es also Sinnvoller für jede Tabelle einen Eindeutigen Feldnamen zu verwenden, oder wird das i.d.R. eher nicht gemacht oder muss das jeder für sich selbst entscheiden, ohner das es dafür allegemeingültige Empfehlungen gibt.
ciao
Lothar
Ich bin gerade dabei eine Datenbank neu zu strukturieren und zu konsolidieren, um einiges an "Altlasten" rauszubekommen und diese für neue Anforderungen umzustellen und vorzubereiten
Dabei bin ich wiedereinmal darüber gestolpert, daß in der derzeitegen DB. nahezu alle Primärschlüssel den Feldnamen "Nr" oder "Auto_ID" haben (als autoincrement).
Kurze und knappe Frage:
Gibt es eigentlich sowas wie eine Empfehlung für die Benennung der Feldnamen von Datensatzbezeichnern / Primärinexen?
Ist es also Sinnvoller für jede Tabelle einen Eindeutigen Feldnamen zu verwenden, oder wird das i.d.R. eher nicht gemacht oder muss das jeder für sich selbst entscheiden, ohner das es dafür allegemeingültige Empfehlungen gibt.
ciao
Lothar
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 208293
Url: https://administrator.de/forum/best-practice-feldname-fuer-datensatzbezeichner-bzw-primaerindex-208293.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
7 Kommentare
Neuester Kommentar
Hi!
naja das kommt drauf an...
Sprechende Namen haben immer den Vorteil, dass sie das programmieren erleichtern können. wenn du sowieso immer die Tabelle angibst - ist Tabelle.id wieder kürzer.
sg Dirm
naja das kommt drauf an...
Sprechende Namen haben immer den Vorteil, dass sie das programmieren erleichtern können. wenn du sowieso immer die Tabelle angibst - ist Tabelle.id wieder kürzer.
sg Dirm
Also entscheiden nach eigenem "Gusto"!
Wobei ich zu eindeutigen "sprechenden" Namen tendiere.
Wobei ich zu eindeutigen "sprechenden" Namen tendiere.
wichtig ist nur, dass es einheitlich ist!
Moin Digi-Quick,
selbstverständlich sollten die Feldnamen eindeutig sein.
Auch eine Autoincrement-ID in einer Kunden-Tabelle (also Kunden.ID ist fachlich und auch im logischen Datenmodell eine andere Entität als eine Autoincrement-ID im Ticket-System (also Ticket.ID)
Welchen Wartungsvorteil sollte es denn haben, in jeder Tabelle ein PK-Feld mamens "ID" oder "Nr" zu haben?
Soll ich dann mal ein Selectstatement mit 18 verjointen und verunionten Tabellen konstruieren?
Außerdem wäre dann ja die weitergedachte Konsequenz, dass auch die Nicht-PK-Felder ein bisschen weniger phantasievoll gestaltet werden könnten.
Die könntest du auch ganz toll runtercopy&pasten als CHARFELD01, CHARFELD02, DATEFELD01, DATEFELD02 etc in jeder Tabelle.
Dann hast du beim Tabellen-Anlegen ganz viele Tippsekunden gespart, die du 100fach wieder draufzahlst, wenn du irgendwann mal die Tabellenstruktur dokumentieren oder offenlegen musst.
Kurz: ein PK KundenID heisst auch KundenID. und nicht ID.
Grüße
Biber
selbstverständlich sollten die Feldnamen eindeutig sein.
Auch eine Autoincrement-ID in einer Kunden-Tabelle (also Kunden.ID ist fachlich und auch im logischen Datenmodell eine andere Entität als eine Autoincrement-ID im Ticket-System (also Ticket.ID)
Welchen Wartungsvorteil sollte es denn haben, in jeder Tabelle ein PK-Feld mamens "ID" oder "Nr" zu haben?
Soll ich dann mal ein Selectstatement mit 18 verjointen und verunionten Tabellen konstruieren?
Außerdem wäre dann ja die weitergedachte Konsequenz, dass auch die Nicht-PK-Felder ein bisschen weniger phantasievoll gestaltet werden könnten.
Die könntest du auch ganz toll runtercopy&pasten als CHARFELD01, CHARFELD02, DATEFELD01, DATEFELD02 etc in jeder Tabelle.
Dann hast du beim Tabellen-Anlegen ganz viele Tippsekunden gespart, die du 100fach wieder draufzahlst, wenn du irgendwann mal die Tabellenstruktur dokumentieren oder offenlegen musst.
Kurz: ein PK KundenID heisst auch KundenID. und nicht ID.
Grüße
Biber
Danke Biber, das ist auch meine Einschätzung 
unser Webseitenprogrammierer sieht das anders, bei ihm heissen Variablen aber auch a,b, c,... x etc. - und niemand anderess ausser Ihm kann da jemals durchblicken - entsprechend Kommentiert ist das nämlich auch nicht.
Aber auch er hat schon die Ansage bekommen sprechende Variablennamen zu verwenden....
Mal schauen, ob wir mit einer Projektdauer von 1 Jahr auskommen.
Es ist natürlich in den letzten 12 Jahren da unheimlich viel gestrickt und gebastelt worden - es soll sozusagen bei Null neu aufgebaut werden und vernünftig strukturiert werden.
Wobei auch ich mir auf die Finger klopfen muss - ich hatte in der Vergangenheit einige male Variablen sozusagen Recycled und doppelt verwendet - macht das spätere Nachvollziehen nicht gerade leichter
ciao
Lothar
unser Webseitenprogrammierer sieht das anders, bei ihm heissen Variablen aber auch a,b, c,... x etc. - und niemand anderess ausser Ihm kann da jemals durchblicken - entsprechend Kommentiert ist das nämlich auch nicht.
Aber auch er hat schon die Ansage bekommen sprechende Variablennamen zu verwenden....
Mal schauen, ob wir mit einer Projektdauer von 1 Jahr auskommen.
Es ist natürlich in den letzten 12 Jahren da unheimlich viel gestrickt und gebastelt worden - es soll sozusagen bei Null neu aufgebaut werden und vernünftig strukturiert werden.
Wobei auch ich mir auf die Finger klopfen muss - ich hatte in der Vergangenheit einige male Variablen sozusagen Recycled und doppelt verwendet - macht das spätere Nachvollziehen nicht gerade leichter
ciao
Lothar
Hallo,
Externe Firma oder eigene Mitarbeiter?
Wenn das ganze aber von einem Externen gemcht wird, Pech, das ist dann sein ding. Ansonsten gehört soetwas geregelt und wer sich nicht dran hält kassiert notfalls auch eine Abmahnung oder schlimmeres. Wie die Namen aber geregelt sind bleibt eurer Phanstasie überlassen, wobei allerdings sprechende namen sinnvoll sind und alle diese dann verwenden.
Das einführen von Standards an den sich gerade Programmierer halten sollen kann schwieriger sein als den Quellcode für das ganze Projekt zu schreiben
mist Programmierstil und "meine Variablen nennn sich immer so" seit Jahren in sein Kopf drin. Ausgetretene Pfade ...
ausgetauscht wurden damit es eben funktioniert und neuer Quellcode zum Erfolg führen konnte...
Gruß,
Peter
Externe Firma oder eigene Mitarbeiter?
sieht das anders
Gibt es bei euch kein Regelwerk was dies Betrifft an der siche jeder halten muss?bei ihm heissen Variablen aber auch a,b, c,... x
Sehr klug ... und dämmlich. Dieser Programmierer beweisst doch das er sein Handwerk nicht gelernt hat. Und unfähige Leute proggramieren bei euch?- und niemand anderess ausser Ihm kann da jemals durchblicken
Spätestens auf der zweitenQquellcode seite kann er ohne nachzuschauen es auch nicht mehr...- entsprechend Kommentiert ist das nämlich auch nicht
Ist es bei euch keine Arbeitsanweisung?Wenn das ganze aber von einem Externen gemcht wird, Pech, das ist dann sein ding. Ansonsten gehört soetwas geregelt und wer sich nicht dran hält kassiert notfalls auch eine Abmahnung oder schlimmeres. Wie die Namen aber geregelt sind bleibt eurer Phanstasie überlassen, wobei allerdings sprechende namen sinnvoll sind und alle diese dann verwenden.
Das einführen von Standards an den sich gerade Programmierer halten sollen kann schwieriger sein als den Quellcode für das ganze Projekt zu schreiben
es soll sozusagen bei Null neu aufgebaut werden
Sehr schwierig. Jeder der Entwickler hat doch seinen und vernünftig strukturiert werden.
Ich habe schon erlebt das hier die ganzen EntwicklerGruß,
Peter
Der Webseitenprogrammierer ist tatsächlich ein externer - genau wie ich.
Die Firma um die es geht besteht aus dem Chef, und 5 Mitarbeitern.
Die Datenbank und die ursprüngliche Programmierung hat er noch als "Laie" selbst entwickelt - Access Datenbank und Envox zur Progarmmierung (Envox ist eigentlich 'ne schöne Sache, nur halt 'ne Insellösung). Für Envox hatte er eine Schulung mitgemacht.
Ende 2006 haben wir die Datenbank auf MySQl portiert - Benutzerfrontend mit Kundenformular läuft setdem weiterhin auf Access 2003.
Seitdem Programmiere ich einen grossteil der Änderungen in Envox (nach Einweisung in das Programm vom Chef). Mittlerweiel kann man fast sagen, daß gut 50 % der Progarmmierung auf meinem "Mist" gewachsen ist. ich habe auch schon einen sehr grossen Teil neu progranmmiert und etwas mehr Strukturiert.
Ich bin zwar kein gelernter Programmierer, habe aber ein recht grosses Verständnis dafür. PAPL etc. ist für mich kein Fremdwort.
Wobei die Envox IDE mit Programmieren im eigentlichen Sinne nur wenig zu tun hat. weil Ennvox mit Block-Modulen arbeitet - ein gewisse Ähnlichkeit zu PAPL kann man nicht von der Hand weisen.
Raus kommt ein Script, welches dann von der Envox Server-Engine abgearbeitet wird.
Aiuf jeden Fall haben wir zum Teil in gemeinsamer Arbeit in den letzten Jahren immer wieder Sachen dazuprogrammiert oder mussten Teile ändern etc.
Für zukünftige Planungen und mögliche Aufgabenstellungen, ist die derzeitige Struktur so ziemlich festgefahren, daher fiel jetzt die Entscheidung mit 'ne Neutrukturierunng zu beginnen, bevor wir weiter Stricken müssen und doch nicht alles umgesetzt bekommen, weil es strukturell einfach nicht geht.
Regekwerk, Arbeitsanweisung? was ist das?
Als Selfmade Programmierer und Chef fängt man einfach an *gfg*
Da sind wir jetzt aber dran, da auch der Chef eine gewisse Notwendigkeit dazu erkannt hat - das kam auf unsererm Meeting jedenfalls zur Sprache..
wir haben gerade vor 2 Wochen ein Meeting gehabt, zum Thema Neustrukturierung gehabt, weil durch gewachsene Struktur einfach zuviele Leichen in der Datenbank und der dazugehörigen Prorammirung sind. Wir sind an einem Punk angekommen, wo man nicht mehr Stricken kann.
Es wird auf jeden Fall Spannend.
Es ist auch geplant in diesem Zuge von Envox wegzugehen (bzw. Envox wird nur noch als Telefoniesystem arbeiten).
Das heisst für mich - Visual Basic lernen.bzw, rudimentäre Kenntnisse massiv aufbohren. - Man lernt nie aus
Im Moment bin ich mir allkerdings noch nicht so ganz schlüssig, ob C# oder C++ nicht sogar geeigneter wäre. ich muss mich da mal einlesen. Aber ein Schritt nach dem anderen - das Grauen kommt von alleine *gg*.
ciao
Lothar
P.S. Zur Uersprungsfrage: Wir haben uns darauf geeinigt bei einzelnen "Solo" Tabellen, wo das Feld nur die Funktion "eindeutiger Datensatzbezeichner" hat, der funktionell eigentlich gar nicht benötigt wird, bleiben die Feldnamen wie sie sind - also wie einfache Excel Tabellen funktionieren.
Bei verknüpften Tabellen, oder Tabellen wo der Datensatzbezeichner tatsächlich auch funktionell benötigt wird, bekommt das Feld einen eindeutigen Namen.
Die Firma um die es geht besteht aus dem Chef, und 5 Mitarbeitern.
Die Datenbank und die ursprüngliche Programmierung hat er noch als "Laie" selbst entwickelt - Access Datenbank und Envox zur Progarmmierung (Envox ist eigentlich 'ne schöne Sache, nur halt 'ne Insellösung). Für Envox hatte er eine Schulung mitgemacht.
Ende 2006 haben wir die Datenbank auf MySQl portiert - Benutzerfrontend mit Kundenformular läuft setdem weiterhin auf Access 2003.
Seitdem Programmiere ich einen grossteil der Änderungen in Envox (nach Einweisung in das Programm vom Chef). Mittlerweiel kann man fast sagen, daß gut 50 % der Progarmmierung auf meinem "Mist" gewachsen ist. ich habe auch schon einen sehr grossen Teil neu progranmmiert und etwas mehr Strukturiert.
Ich bin zwar kein gelernter Programmierer, habe aber ein recht grosses Verständnis dafür. PAPL etc. ist für mich kein Fremdwort.
Wobei die Envox IDE mit Programmieren im eigentlichen Sinne nur wenig zu tun hat. weil Ennvox mit Block-Modulen arbeitet - ein gewisse Ähnlichkeit zu PAPL kann man nicht von der Hand weisen.
Raus kommt ein Script, welches dann von der Envox Server-Engine abgearbeitet wird.
Aiuf jeden Fall haben wir zum Teil in gemeinsamer Arbeit in den letzten Jahren immer wieder Sachen dazuprogrammiert oder mussten Teile ändern etc.
Für zukünftige Planungen und mögliche Aufgabenstellungen, ist die derzeitige Struktur so ziemlich festgefahren, daher fiel jetzt die Entscheidung mit 'ne Neutrukturierunng zu beginnen, bevor wir weiter Stricken müssen und doch nicht alles umgesetzt bekommen, weil es strukturell einfach nicht geht.
Regekwerk, Arbeitsanweisung? was ist das?
Als Selfmade Programmierer und Chef fängt man einfach an *gfg*
Da sind wir jetzt aber dran, da auch der Chef eine gewisse Notwendigkeit dazu erkannt hat - das kam auf unsererm Meeting jedenfalls zur Sprache..
wir haben gerade vor 2 Wochen ein Meeting gehabt, zum Thema Neustrukturierung gehabt, weil durch gewachsene Struktur einfach zuviele Leichen in der Datenbank und der dazugehörigen Prorammirung sind. Wir sind an einem Punk angekommen, wo man nicht mehr Stricken kann.
Es wird auf jeden Fall Spannend.
Es ist auch geplant in diesem Zuge von Envox wegzugehen (bzw. Envox wird nur noch als Telefoniesystem arbeiten).
Das heisst für mich - Visual Basic lernen.bzw, rudimentäre Kenntnisse massiv aufbohren. - Man lernt nie aus
Im Moment bin ich mir allkerdings noch nicht so ganz schlüssig, ob C# oder C++ nicht sogar geeigneter wäre. ich muss mich da mal einlesen. Aber ein Schritt nach dem anderen - das Grauen kommt von alleine *gg*.
ciao
Lothar
P.S. Zur Uersprungsfrage: Wir haben uns darauf geeinigt bei einzelnen "Solo" Tabellen, wo das Feld nur die Funktion "eindeutiger Datensatzbezeichner" hat, der funktionell eigentlich gar nicht benötigt wird, bleiben die Feldnamen wie sie sind - also wie einfache Excel Tabellen funktionieren.
Bei verknüpften Tabellen, oder Tabellen wo der Datensatzbezeichner tatsächlich auch funktionell benötigt wird, bekommt das Feld einen eindeutigen Namen.
