nicht angemeldet
Zusatzfrage zu unten von "wpo" gleichzeitiger Datenbankzugriff
Hallo!
Die Frage weiter unten hat IMHO nur am Rande mit meiner zu tun.
Deshalb der neue Thread.
Ich hatte mal eine Funktion zur Bestellnummernverteilung.
Dabei stellte sich mir das Problem, dass ich Auto-Increament nicht nutzen konnte weil ja Artikel auch gelöscht und eingefügt werden können.
Man kann sich das in etwa so vorstellen, dass Artikelnummern 100 bis 999 vergeben sind und irgendwann 107 gelöscht wird.
Im Prinzip ist die 107 ja dann "frei".
Jetzt habe ich verschiedene Artikelgruppen.
Ich hatte das so gelöst:
Pro Artikelgruppe eine jeweilige Zahl am Anfang der Bestellnummer
(z.B. 3 für Tonträger), dahinter eine per zufall generierte 3-stellige Zahl,
sodaß insgesamt eine 4-stellige Bestellnummer raus kommt.
Sinnvoll erschien mir das beim Einfügen der Artikel, denn so ergab Artikelgruppe.Zufallszahl eine schön ansprechbare Bestellnummer.
Damit die generierte bstnr aber nicht schon vergeben ist, wird solange generiert bis es per Überprüfung keine Übereinstimmung gibt.
Es kommt beim Einfügen der Artikel jetzt aber vor, dass das verschiedene Menschen, an verschiedenen Rechnern gleichzeitig tun.
Kann es dabei passieren das eine bstnr doppelt vergeben wird?
Konntet Ihr mir folgen?
Danke,
Christian
-
yo,
Dabei stellte sich mir das Problem, dass ich Auto-Increament nicht nutzen konnte weil ja Artikel auch gelöscht und eingefügt werden können.
das ist unsinn, man kann sehr gut auto-increment werte nutzen, obwohl datensätze gelöscht werden. es schränkt die funktionalität eines pk in keinster weise ein, wenn es zu "lücken" kommt.
Pro Artikelgruppe eine jeweilige Zahl am Anfang der Bestellnummer
(z.B. 3 für Tonträger), dahinter eine per zufall generierte 3-stellige Zahl,
sodaß insgesamt eine 4-stellige Bestellnummer raus kommt.das sind sogenannte "sprechende schlüssel". in aller regel werden diese heute nur noch selten genutzt und gerade in deinem fall würde ich dir davon abraten und einen künstlichen schlüssel verwenden (auto-increment). man kann dann einen weiteren eindeutigen namen (bestellnummer) auf wunsch zusätzlich hinzufügen.
Es kommt beim Einfügen der Artikel jetzt aber vor, dass das verschiedene Menschen, an verschiedenen Rechnern gleichzeitig tun.
Kann es dabei passieren das eine bstnr doppelt vergeben wird?genau dieses problem kann eintreten und würde durch ein auto-increment verhindert werden.
Ilja
-
Auch "yo"
das ist unsinn, man kann sehr gut auto-increment werte nutzen, obwohl datensätze gelöscht werden. es schränkt die funktionalität eines pk in keinster weise ein, wenn es zu "lücken" kommt.
Was ist "pk"? Und kannst du mir sagen wie das geht, das die "lücken" automatisch gefüllt werden? Und mit was denn dann? Mit dem alten Wert oder letzter Datensatz+1? Ich versteh das nicht ganz. Sry.
das sind sogenannte "sprechende schlüssel". in aller regel werden diese heute nur noch selten genutzt und gerade in deinem fall würde ich dir davon abraten und einen künstlichen schlüssel verwenden (auto-increment). man kann dann einen weiteren eindeutigen namen (bestellnummer) auf wunsch zusätzlich hinzufügen.
Wozu beides? Mir ging es nur um eine eindeutige Identifizierung.
Was sollten 2 Spalten zur Identifizierung für einen Sinn machen?genau dieses problem kann eintreten und würde durch ein auto-increment verhindert werden.
Aha. Zumindest ist es bis jetzt noch nicht passiert ;)
Danke!
Christian
-
yo,
Was ist "pk"? Und kannst du mir sagen wie das geht, das die "lücken" automatisch gefüllt werden? Und mit was denn dann? Mit dem alten Wert oder letzter Datensatz+1? Ich versteh das nicht ganz. Sry.
ein pk ist die abkürzung für einen primary key, der einen datensatz eindeutig identifiziert. und genau das ist auch schon die einzige aufgabe eines pk. deshalb musst du lücken gar nicht füllen, es macht keine sinn, es zu versuchen. wenn lücken entstehen, dann lass sie bestehen. dadurch hast du keinen nachteil.
Wozu beides? Mir ging es nur um eine eindeutige Identifizierung.
Was sollten 2 Spalten zur Identifizierung für einen Sinn machen?grundsätzlich reicht ein pk pro tabelle. heutzutage nimmt man dafür in aller regel einen künstlichen schlüssel, sprich einen auto-incrementwert. es kann aber gut sein, dass man für manche tabellen (entiäten) zusätzlich noch einen zweiten eindeutigen bezeichner haben will, zum beispiel eine produktname. der künstliche pk dient mehr oder weniger der datenbank, um den datensatz eindeutig zu identifizieren und der produktname hilft uns menschen, das ding bei einem namen zu nennen.
Ilja
-
Hallo!
ein pk ist die abkürzung für einen primary key, der einen datensatz eindeutig identifiziert. und genau das ist auch schon die einzige aufgabe eines pk. deshalb musst du lücken gar nicht füllen, es macht keine sinn, es zu versuchen. wenn lücken entstehen, dann lass sie bestehen. dadurch hast du keinen nachteil.
Doch, es befinden sich in dem Fall mehrere Artikelgruppen in einer Tabelle und z.B. Tonträger können 3001 bis 3999 kriegen. Ab da gehts ja mit einer anderen weiter. Wenn ich jetzt die gelöschten Werte nicht ersetze habe ich 1000 Artikel schnell erreicht und mein Konzept haut nicht mehr hin.
Danke, Christian.
-
yo,
Doch, es befinden sich in dem Fall mehrere Artikelgruppen in einer Tabelle und z.B. Tonträger können 3001 bis 3999 kriegen. Ab da gehts ja mit einer anderen weiter. Wenn ich jetzt die gelöschten Werte nicht ersetze habe ich 1000 Artikel schnell erreicht und mein Konzept haut nicht mehr hin.
du hast das prinzip eines pk noch nicht verstanden. der pk hat als einzige fumktion die identifizierung. alle weitere funktionen wie du sie nennst können durchaus zu problemen führen. deshalb wendet man in aller regel heute keine sprechende schlüssel mehr an. die ausnahme bestätigt die regl.
um welchen typ (artikelgruppe) es sich handelt, wird in aller regel anders durch eine weitere tabelle gelöst. aber ich befürchte, du wirst das hier nicht mehr lesen.....
Ilja
-
Hallo!
um welchen typ (artikelgruppe) es sich handelt, wird in aller regel anders durch eine weitere tabelle gelöst.
Ich wollte ganz einfach mehrere Tabellen vermeiden.
aber ich befürchte, du wirst das hier nicht mehr lesen.....
Wieso nicht?
Danke, Christian
-
yo,
Ich wollte ganz einfach mehrere Tabellen vermeiden.
das ist generell keine schlechte idee, aber man sollte vor und nachteile abwägen. grundsätzlich würde ich sagen, falls deine abfragen durch zuviele tabellen zu langsam werden, wenn zum beispiel große datenmengen vorhanden sind, dann macht es sinn.
aber selbst dann, würde ich das nicht über den pk machen, sondern in einer extra spalte. zum beispiel bräuchten dann die tonträger nicht mehrere, bestimmte, fortlaufende nummmern über den pk, sondern nur noch eine einheitliche nummer und lassen sich somit leichter verwalten und durch abfragen ansprechen. zum beispiel können Tonträger dann den wert 1 haben oder aber unverschlüsselt den wert "Tonträger". ich habe das mal ähnlich gelöst, um mir joins über mehrere tabellen zu sparen.
aber ich befürchte, du wirst das hier nicht mehr lesen.....
Wieso nicht?
war nur eine falsche vorahnung von mir, meine "weibliche intuition" läßt halt zu wünschen übrig....
Ilja
-
Hallo Ilja!
grundsätzlich würde ich sagen, falls deine abfragen durch zuviele tabellen zu langsam werden, wenn zum beispiel große datenmengen vorhanden sind, dann macht es sinn.
Also meinst du ein Shop hat nicht so viel Daten sodass ich mir das sparen kann? Ich sag auch gleich mal das ca. 8000 Artikel drin stehen.
aber selbst dann, würde ich das nicht über den pk machen, sondern in einer extra spalte. zum beispiel bräuchten dann die tonträger nicht mehrere, bestimmte, fortlaufende nummmern über den pk, sondern nur noch eine einheitliche nummer und lassen sich somit leichter verwalten und durch abfragen ansprechen. zum beispiel können Tonträger dann den wert 1 haben oder aber unverschlüsselt den wert "Tonträger".
Auch keine schlechte Lösung.
Dann danke ich dir! Ich glaub ich habs verstanden :)Danke, Christian
-
-
-
-
-
-
-