Datenmodell, Zähler immer von Vorne beginnen lassen?
1 0 1 0 0 0 0 0 
dedlfix
0
0
Datenmodell, Zähler immer von Vorne beginnen lassen?
Hallo,
ich habe folgendes Datenmodell:
Folgender Ablauf:
Ein Kunde kann mehrere Mitreisende haben. Dadurch musste ich dem Primary Key ein zusätzliches Attribut verpassen (MR_mitreisendernr, als Typ SERIAL (Postgre) (=autoincrement bei anderen DBs))
Nun habe ich aber folgendes Problem:
Der Zähler MR_mitreisendernr zählt natürlich immer weiter hoch, was mir gar nicht gefällt. Ich hätte gerne, dass für jeden Kunden der Zähler irgendwie von vorne beginnt, oder eine andere Lösung.
Ich will vom Programm diesen Vorgang nicht steuern lassen (d.h. einfach immer einen Wert zuweisen lassen, was ja die einfachste Lösung wäre), da es aber wieder eine unnötige Interaktion mit dem Programm erfordert, die ich vermeiden will.
Wie könnte ich es am besten lösen, sodass keine Programmlogik erforderlich ist um einen eindeutigen Primary Key zu bekommen, der aber nicht kontinuierlich hochzählt, sondern bei jedem Kunden wieder von vorne anfängt?
Markus
-
Hi,
Der Zähler MR_mitreisendernr zählt natürlich immer weiter hoch, was mir gar nicht gefällt.
warum nicht?
Ich hätte gerne, dass für jeden Kunden der Zähler irgendwie von vorne beginnt, oder eine andere Lösung.
Der explizite Wert eines Primary Keys ist absolut egal. Es muss lediglich die Eindeutigkeit gewährleistet werden. Wenn bei einem kombinierten PK eine der Spalten bereits Unique ist, ist diese notwendige *und* hinreichende Voraussetzung erfüllt. Andere Anforderungen existieren nicht.
Wie könnte ich es am besten lösen, sodass keine Programmlogik erforderlich ist um einen eindeutigen Primary Key zu bekommen, der aber nicht kontinuierlich hochzählt, sondern bei jedem Kunden wieder von vorne anfängt?
Es ist unerheblich, ob die Zahlen bereichsweise hochzählen, dies global tun, scheinbar zufällig über den gesamten Zahlenraum verteilt sind oder aus kreativen Schimpfwörtern bestehen. Ein PK könnte die Fingerabdrücke einzelner Menschen repräsentieren - das spielt keine Rolle. Er muss *nur und ausschließlich* eindeutig sein.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi,
Der Zähler MR_mitreisendernr zählt natürlich immer weiter hoch, was mir gar nicht gefällt.
warum nicht?
Nun, wie verhält sich der Zähler eigentlich, wenn er am Ende angelangt ist? Beginnt er dann wieder von vorne?
Der explizite Wert eines Primary Keys ist absolut egal. Es muss lediglich die Eindeutigkeit gewährleistet werden. Wenn bei einem kombinierten PK eine der Spalten bereits Unique ist, ist diese notwendige *und* hinreichende Voraussetzung erfüllt. Andere Anforderungen existieren nicht.
Das ist mir schon klar. Allerdings kann ich die Spalten dazu nicht verwenden. Was wäre, wenn der Kunde Zwillinge als Mitreisende hat, die auch noch gleich heißen?
Hinzu kommt dann noch die Tatsache, dass der Primary Key unnötig aufgebläht würde.-
Hi,
Nun, wie verhält sich der Zähler eigentlich, wenn er am Ende angelangt ist? Beginnt er dann wieder von vorne?
das hängt vom DBMS und dessen Einstellungen ab.
Der explizite Wert eines Primary Keys ist absolut egal. Es muss lediglich die Eindeutigkeit gewährleistet werden. Wenn bei einem kombinierten PK eine der Spalten bereits Unique ist, ist diese notwendige *und* hinreichende Voraussetzung erfüllt. Andere Anforderungen existieren nicht.
Das ist mir schon klar. Allerdings kann ich die Spalten dazu nicht verwenden. Was wäre, wenn der Kunde Zwillinge als Mitreisende hat, die auch noch gleich heißen?Ich nehme an, diese Zwillinge hätten unterschiedliche Identifier. Bei einem auf Fingerabdrücken basierenden Primary Key gäbe es beispielsweise kein Problem.
Hinzu kommt dann noch die Tatsache, dass der Primary Key unnötig aufgebläht würde.
Nun ja. Ist die Kundennummer zur Identifizierung des Datensatzes nötig? Wenn nicht, lass sie aus dem PK raus.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes -
Hallo!
Nun, wie verhält sich der Zähler eigentlich, wenn er am Ende angelangt ist? Beginnt er dann wieder von vorne?
Weiß ich ehrlich gesagt nicht. Aber bei Verwendung on bigserial, die bis 9223372036854775807 geht, hätte ich gerne den Anwendungsfall gesehen, der damit nicht auskommt.
mfg
frafu-
Moin Moin!
Weiß ich ehrlich gesagt nicht. Aber bei Verwendung on bigserial, die bis 9223372036854775807 geht, hätte ich gerne den Anwendungsfall gesehen, der damit nicht auskommt.
Atome im Universum erfassen.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hallo!
Weiß ich ehrlich gesagt nicht. Aber bei Verwendung on bigserial, die bis 9223372036854775807 geht, hätte ich gerne den Anwendungsfall gesehen, der damit nicht auskommt.
Atome im Universum erfassen.
Ja, an das hab ich beim Schreiben meines Postings auch gedacht aber leider nicht erwähnt. :-)
Angeblich sind das so ca 10^78. Wieviele Bit müsste ein nicht vorzeichenbehafteter, ganzzahliger Datentyp haben um diese Zahl erfassen zu können?mfg
frafu-
Ahoj!
Weiß ich ehrlich gesagt nicht. Aber bei Verwendung on bigserial, die bis 9223372036854775807 geht, hätte ich gerne den Anwendungsfall gesehen, der damit nicht auskommt.
Atome im Universum erfassen.
Ja, an das hab ich beim Schreiben meines Postings auch gedacht aber leider nicht erwähnt. :-)
Angeblich sind das so ca 10^78. Wieviele Bit müsste ein nicht vorzeichenbehafteter, ganzzahliger Datentyp haben um diese Zahl erfassen zu können?260 bit, wenn ich mich nicht verrechnet habe. Die größte Schwierigkeit dürfte darin liegen, ein Speichermedium zu erschaffen, daß höchstens ein Atom für jeden Datensatz braucht. ;-)
Viele Grüße vom Længlich
--
Mein aktueller Gruß ist:
Tschechisch-
echo $begrüßung;
Die größte Schwierigkeit dürfte darin liegen, ein Speichermedium zu erschaffen, daß höchstens ein Atom für jeden Datensatz braucht. ;-)
Es existiert und wird von uns Universum genannt.
echo "$verabschiedung $name";
-
-
-
Hi,
Aber bei Verwendung on bigserial, die bis 9223372036854775807 geht, hätte ich gerne den Anwendungsfall gesehen, der damit nicht auskommt.
Atome im Universum erfassen.
Willst du andeuten, dass wenn ich bspw. Personen in einer Datenbank erfasse, statt der einzelnen Atome, aus denen sie jeweils bestehen - ich dann nicht in ausreichendem Masze normalisiert haette ...?
MfG ChrisB
-
-
-
-
yo,
Der explizite Wert eines Primary Keys ist absolut egal. Es muss lediglich die Eindeutigkeit gewährleistet werden.
das ist so nicht richtig. eine spalte, die UNIQUE ist, erfüllt nicht automatisch die eigenschaften eines PK.
Ilja
-