Hallo,

was sind für Euch die Vorteile/Nachteile, wenn man Kundennummern neu anlegt mit Datentyp Char/Integer dazu noch autoinc ?

da du nicht geschrieben hast auf welches dbms du dich beziehst sag ichs mal "allgemein"

je nach aufgabengebiet bietet sich eine reine integer-nummer an, wenn nicht würde ich auf char wechseln ohne autoinc

vorteil:

-du hast keine arbeit bei deiner kundennummer (-> autoinc)

-möglichkeit der history-funktion, da eine ID nur einmal benutzt wird, egal ob sie im nachhinein gelöscht wird oder nicht

nachteil:

-wenn du nen kunde löschst ist diese "ID" weg, ohne autoinc könntest du das ausgleichen indem du nach der ersten freien nummer suchst und diese verwendest (für eine history ist das allerdings ungeeignet, da es u.u. sein kann, dass mehrere kunden über die laufzeit dieselbe kundennummer bekommen könnten und du keine direkte zuweisung mehr hast)

gibt sicher noch etliche weitere vor-/nachteile aber meine mittagspause ist rum

numerische Typen würde ich dann einsetzen, wenn ich einfach nur eine Nummerierung haben will. Als Charactertypen bietet es sich an, wenn Du z.B. solche Kombinationen haben willst DE12345. Das wäre dann eine Kombi aus Char + Nummer mit AutoInc. Viele Datenbanken unterstützen Sequenzen, die solche eindeutigen Schlüssel generieren können

Ist aber letztendlich von der Problemstellung abhängig

Phil

Das DBMS wäre: Advantage Database Server

sonst wie gesagt würde mich noch ein richtiger Vorteil FÜR die alphanumerische Variante interessieren.

nachteil:

-wenn du nen kunde löschst ist diese "ID" weg, ohne autoinc könntest du das ausgleichen indem du nach der ersten freien nummer suchst und diese verwendest (für eine history ist das allerdings ungeeignet, da es u.u. sein kann, dass mehrere kunden über die laufzeit dieselbe kundennummer bekommen könnten und du keine direkte zuweisung mehr hast)

- Na ja, und wenn die Kunden_ID als Referenz (ForeignKey) in diversen weiteren Enitäten referenziert wird, wirds schwierig mit "Suche nach wieder freigewordenen Nummern...).

Gruss

nach aussen referenzieren solltest du eh NUR mit dem primary key der tabelle. Kudennummer ist eher für Rechnungen, Support-tickets und so Sachen wichtig / intresannt.

Bei sowas joinst du dann aber mit der Kundentabelle über die Kundennummer, und arbeitest mit dem Primary key weiter bei den diversen anderen Tabellen. Da kannst du dir dann nämlich recht sicher sein das kein Murks rauskommt am schluss.

So gesehn, kannste das Format von der Kundennummer beliebig wählen. Es zwingt dich ja keiner dazu, den Primary Key der Kundentabelle auch als offizielle Kundennummer zu verwenden.

Das DBMS wäre: Advantage Database Server

sonst wie gesagt würde mich noch ein richtiger Vorteil FÜR die alphanumerische Variante interessieren.

- Für einen technischen Schlüssel würde ich immer auf einen numerischen Wert gehen, du kanst ja jederzeit noch einen fachlichen Schlüssel zufügen, welcher wie auch immer aufgebaut ist, als PK aber den technischen Schlüssel verwenden.

Alpahnumerische Schlüssel sind "schwieriger" zu handhaben in Bezug auf "hochzählen" und bieten keinerlei Vorteil gegenüber einem numerischen Wert

Gruss

Für einen technischen Schlüssel würde ich immer auf einen numerischen Wert gehen, du kanst ja jederzeit noch einen fachlichen Schlüssel zufügen, welcher wie auch immer aufgebaut ist, als PK aber den technischen Schlüssel verwenden.

Das widerspricht aber der Normalisierung, denn der Schlüssel soll ein eindeutiges Kriterium ohne Redundanz fest legen. Mit 2 Schlüsseln, die beide eindeutig sind und nicht referenziert werden, habe ich 2 Schlüssel für den gleichen Datensatz.

Alpahnumerische Schlüssel sind "schwieriger" zu handhaben in Bezug auf "hochzählen" und bieten keinerlei Vorteil gegenüber einem numerischen Wert

Das simmt so nicht. Stored Procedure bzw Sequenzgeneratoren übernehmen diese Aufgabe. Da diese Aufgabe auch nicht in die Anwendungslogik gehört, wird es eh nur innerhalb der Datenbank ausgeführt.

Phil

Das widerspricht aber der Normalisierung, denn der Schlüssel soll ein eindeutiges Kriterium ohne Redundanz fest legen. Mit 2 Schlüsseln, die beide eindeutig sind und nicht referenziert werden, habe ich 2 Schlüssel für den gleichen Datensatz.

Phil

- Da hast du im Prinzip recht, ich wollte nur auf die Schwierigkeit hinweisen, in der Praxis eine "guten" PK zu finden, welcher die Anforderungen an einen PK erfüllt, aus diesem Grunde der "technische" Schlüssel. Referenziert in Bezug auf Datenmodel / Relationen wird natürlich nur der eigentliche PK.

Das simmt so nicht. Stored Procedure bzw Sequenzgeneratoren übernehmen diese Aufgabe. Da diese Aufgabe auch nicht in die Anwendungslogik gehört, wird es eh nur innerhalb der Datenbank ausgeführt.

- Ich meinte, es ist "einfacher", nicht "unmöglich"... :-)

gruss

l

Hi,

eine Kundennummer ist ein fachlicher Wert und daher als PK denkbar ungeeignet. Des weiteren haben Kundennummern die ich so kenne meistens eine feste Länge wobei die führenden Stellen ggf. mit Nullen gefüllt sind also z.B. 00034566 Das wäre mit einem numerischen Wert nicht machbar.

Ob Du einen numerischen oder einen varchar Wert verwendest hängt in aller erster Linie also von deinen fachlichen Anforderungen ab. Als PK würde ich auf jeden Fall einen rein technischen Schlüssel wählen, der evtl. auch mit der Kundennummer identisch sein kann oder diese als Bestandteil enthalten kann.

Bei einem alphanumerischen Wert bist Du auf jeden Fall flexibler was den Inhalt betrifft.

Dim

Bearbeitet 28. Juli 200916 j von dr.dimitri

Ich erinner mich mal gehoert zu haben das ein String vergleich "mehr rechenaufwand" als ein Integer vergleich benötigt, ich weis nich wirklich was da dran ist, aber wenn wir hier gerade bei dem Thema sind, koennte man dies ja gleich mitklaeren.

Weil wenn es nachher heist "hol mir ma die Kundendaten aus alle 18390128 Tabellen" duerfte man doch den unterschied schon merken, oder seh ich das falsch?

Ted

Hi,

eine Kundennummer ist ein fachlicher Wert und daher als PK denkbar ungeeignet.

Dim

Eine Kundennummer als PK, was spricht dagegen?

Kundennummer ist eindeutig!

Technische Schlüssel ist eindeutig!

Warum beides nehmen? und nicht gleich die Kundennummer als PK ?

Weil wenn es nachher heist "hol mir ma die Kundendaten aus alle 18390128 Tabellen" duerfte man doch den unterschied schon merken, oder seh ich das falsch?

Ich denke nicht, denn man vergleicht ja nicht Buchstaben sondern Bits (Datavalue1 and not(Datavalue2) == 0 wenn identisch). Aber das sind Dinge die das DBMS intern macht

Phil

Eine Kundennummer als PK, was spricht dagegen?

Weil Daten im allgemeinen eine recht lange Lebensdauer haben und sich die Kundennummer ändern kann. Z.B. wenn neue fachliche Anforderungen kommen, es eine Firmenfusion gibt etc. etc.

In diesen Fällen kann sich die Kdnr ändern oder sie wird in ein neues Feld Kdnralt migriert und der Kunde bekommt eine neue Kdnr. Hast Du darauf jetzt deine RI abgebildet hast erstmal ein Problem und deutlich mehr Migrationsaufwand.

Dahingegen ist das Vergeben eines rein technisches PKs vom Aufwand und von den Kosten her gesehen praktisch 0.

Ich erinner mich mal gehoert zu haben das ein String vergleich "mehr rechenaufwand" als ein Integer vergleich benötigt

Ein String benötigt mehr Speicherplatz als ein Integer. Je nach Zeichensatz ein, zwei oder auch mehr Byte pro Zeichen. Daher muss die DB mehr lesen um die gleiche Anzahl von Datensätzen in den Speicher zu laden - von daher hast Du theoretisch also recht.

Wir verwenden für unsere PKs grundsätzlich 32-stellige GUIDs (ER-Modell hat ca. 120 Tabellen + diverse technische Zusatztabellen) und hatten diesbezüglich nie Performanceprobleme - die kamen zu 100% aus anderen Ecken.

Weil wenn es nachher heist "hol mir ma die Kundendaten aus alle 18390128 Tabellen" duerfte man doch den unterschied schon merken, oder seh ich das falsch?

Bei dieser Anzahl von Tabellen hast ganz andere Probleme

Dim

Bearbeitet 28. Juli 200916 j von dr.dimitri

Wir verwenden für unsere PKs grundsätzlich 32-stellige GUIDs

Das ist eigentlich auch das Beste was man machen kann weil so auch andere Probleme umgeht.

Wenn man den PK stattdessen automatisch von er DB erzeugen lässt hat man z.B. ein Problem wenn man diesen Wert nach dem Anlegen eines neuen Datensatzes braucht weil man diesen dann erst wieder auslesen muss.

Die Guid weißt man einfach vor dem anlegen des Datensatzes zu und merkt sie sich.

Also wir lassen unsere Guid von der DB erzeugen

Dim