Melanin Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 Hallo, was sind für Euch die Vorteile/Nachteile, wenn man Kundennummern neu anlegt mit Datentyp Char/Integer dazu noch autoinc ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Amenos Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Melanin Geschrieben 28. Juli 2009 Autor Teilen Geschrieben 28. Juli 2009 Das DBMS wäre: Advantage Database Server sonst wie gesagt würde mich noch ein richtiger Vorteil FÜR die alphanumerische Variante interessieren. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dbwizard Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
streffin Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dbwizard Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dbwizard Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 (bearbeitet) 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 2009 von dr.dimitri Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
T3D Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Melanin Geschrieben 28. Juli 2009 Autor Teilen Geschrieben 28. Juli 2009 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 ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 28. Juli 2009 Teilen Geschrieben 28. Juli 2009 (bearbeitet) 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 2009 von dr.dimitri Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Guybrush Threepwood Geschrieben 29. Juli 2009 Teilen Geschrieben 29. Juli 2009 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 29. Juli 2009 Teilen Geschrieben 29. Juli 2009 Also wir lassen unsere Guid von der DB erzeugen Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.