sequentielle nummerierung

[lois]

hi,

datenbank z.b.:

id   |   test
------------------
0    |   'str1'
1    |   'str1'
2    |   'str1'
3    |   'str1'
4    |   'str1'

nun lösche ich z.b. den 3. eintrag ->

0    |   'str1'
1    |   'str1'
3    |   'str1'
4    |   'str1'

statt

0    |   'str1'
1    |   'str1'
2    |   'str1'
3    |   'str1'

ich mache das ganze in postgresql und häng schon beim richtigen datentyp für die id. hab da schon mit CREATE INDEX herumprobiert und
CREATE TABLE tst (id SERIAL, text VARCHAR(20))...
will aber nicht.

vielleich weiss ja jemand, wie das geht, dass die erste spalte immer schön der reiche nach nummeriert ist.

thx a lot,
lois.

[Cheatah]

Hi,

vielleich weiss ja jemand, wie das geht, dass die erste spalte immer schön der reiche nach nummeriert ist.

nicht die Spalte muss durchnummeriert sein, sondern das Ergebnis Deiner Abfrage[1] bzw. die Auswertung derselben. Eine ID ist ein IDentifier - er soll einen Datensatz identifizieren, nicht mehr. Oder deutlicher: Er soll _nicht_ etwas anderes machen, als den Datensatz zu identifizieren. Insbesondere soll er _keine_ Nummerierung sein.

Cheatah

[1] Was Dein DBMS - welches immer das sein mag - hierfür zur Verfügung stellt, erfährst Du in dessen Doku. Bei Oracle beispielsweise wäre es die Pseudo-Spalte ROWNUM.

[Lude]

Hi,

nicht die Spalte muss durchnummeriert sein, sondern das Ergebnis Deiner Abfrage[1] bzw. die Auswertung derselben. Eine ID ist ein IDentifier - er soll einen Datensatz identifizieren, nicht mehr. Oder deutlicher: Er soll _nicht_ etwas anderes machen, als den Datensatz zu identifizieren. Insbesondere soll er _keine_ Nummerierung sein.

fuer das Bilden von Eindeutigkeiten verwende ich (RDBMS 'Microsoft SQL Server) idR GUIDs. Wenn ich manchmal fuer denselben Zweck IDs verwende, dann, weil diese benutzerfreundlich sind, sprich einen Index bereitstellen (der ggf. auch angefordert worden ist)

Insofern widerspreche ich Deinen Ausfuerhungen.

Gruss,
LLude

[Klaus Mock]

Hallo,

fuer das Bilden von Eindeutigkeiten verwende ich (RDBMS 'Microsoft SQL Server) idR GUIDs. Wenn ich manchmal fuer denselben Zweck IDs verwende, dann, weil diese benutzerfreundlich sind, sprich einen Index bereitstellen (der ggf. auch angefordert worden ist)

Insofern widerspreche ich Deinen Ausfuerhungen.

Egal, wie man es angeht, Identifikationswerte wiederzuverwenden ist schon vor dem Einsatz von Rechnern    zu Recht verpönt gewesen. Man stelle sich nur vor, wenn eine Firma jahrelang einen Ersatzteil, sagen wir mal eine Schraube mit der ID 1234 verkauft hat. Durch eine 'Neuordnung' der Artikelnummern (in diesem Falle die ID) besitzt plötzlich eine Tiefbohranlage diese ID. Na der Kunde würde sich über eine Lieferung (und Rechnung) für 200 Tiefbohrmaschinen freuen.[1]

Grüße
  Klaus

[1] und sag' jetzt nicht, das ist an den Haaren herbeigezogen. Genau das ist wirklich passiert. Zum Glück hat die Aufrragsbearbeitung ein halbwegs intelligenter Mensch abgewickelt, der den Irrtum rechtzeitig erkannte.

[Lude]

Hi,

Egal, wie man es angeht, Identifikationswerte wiederzuverwenden ist schon vor dem Einsatz von Rechnern    zu Recht verpönt gewesen.

na, man hatte aber schon vor dem Einsatz von Rechnern Leute mit gleichem Vor- und Nachnamen, oder?

Man stelle sich nur vor, wenn eine Firma jahrelang einen Ersatzteil, sagen wir mal eine Schraube mit der ID 1234 verkauft hat.

Durch eine 'Neuordnung' der Artikelnummern (in diesem Falle die ID) besitzt plötzlich eine Tiefbohranlage diese ID. Na der Kunde würde sich über eine Lieferung (und Rechnung) für 200 Tiefbohrmaschinen freuen.[1]

Dass das passiert ist glaube ich gerne. - Wenn man den Identifikationsfeldern Semantik mitgibt, ist das natuerlich nicht unproblematisch, wenn eine "Neuordnung" ansteht. Dann sollte man besser nicht auf die Idee kommen z.B. "Luecken zu fuellen".

Grundsaetzlich hat 'Cheatah' natuerlich wie immer recht. Allerdings kann man m.E. ruhigen Gewissens den Einsatz von numerischen und hochzaehlenden IDs ins Auge fassen, wenn es Sinn macht, also beispielsweise bei Vertragsnummern, deren Werte so kommunizierbar werden. Die Alternative waere im Beispielfall zwei Datenfelder, also z.B. eine GUID fuer die Eindeutigkeit und eine numerisch hochzaehlende ID fuer die "Eindeutigkeit fuer die Benutzer".

Gruss,
Lude

[wahsaga]

hi,

na, man hatte aber schon vor dem Einsatz von Rechnern Leute mit gleichem Vor- und Nachnamen, oder?

die man dann über weitere merkmale wie geburtsdatum, adresse etc. eindeutiger identifiziert hat -> entspricht einem UNIQUE IDENTIFIER in einer DB.

Wenn man den Identifikationsfeldern Semantik mitgibt, ist das natuerlich nicht unproblematisch, wenn eine "Neuordnung" ansteht.

und genau das, der ID semantik mitgeben, machst du doch, wenn du von der ID auf die nummer/position des datensatzes in der (sortierten) gesamtmenge schliessen willst.

Allerdings kann man m.E. ruhigen Gewissens den Einsatz von numerischen und hochzaehlenden IDs ins Auge fassen, wenn es Sinn macht, also beispielsweise bei Vertragsnummern, deren Werte so kommunizierbar werden.

sicher, das ist und bleibt ja auch weitgehend unwidersprochen.
du darfst dann nur nicht hingehen, und aus der ID vertragsnummer 3715 schliessen, dass dies auch dein 3715. vertrag im (geordneten) gesamtbestand wäre.

gruss,
wahsaga

[Cheatah]

Hi,

Egal, wie man es angeht, Identifikationswerte wiederzuverwenden ist schon vor dem Einsatz von Rechnern    zu Recht verpönt gewesen.
na, man hatte aber schon vor dem Einsatz von Rechnern Leute mit gleichem Vor- und Nachnamen, oder?

ja, deswegen gibt es ja auch IDs.

Allerdings kann man m.E. ruhigen Gewissens den Einsatz von numerischen und hochzaehlenden IDs ins Auge fassen, wenn es Sinn macht, also beispielsweise bei Vertragsnummern, deren Werte so kommunizierbar werden.

Das ist kein Problem - wenn die ID nur separat betrachtet wird. Sie mit anderen IDs in einen wie auch immer gearteten Kontext zu bringen (von "unterscheidet sich von allen anderen" abgesehen, versteht sich), ist ein Fehler, der sich irgendwann rächt.

Die Alternative waere im Beispielfall zwei Datenfelder, also z.B. eine GUID fuer die Eindeutigkeit und eine numerisch hochzaehlende ID fuer die "Eindeutigkeit fuer die Benutzer".

Ja. Nur dass die GUID ID heißt und die hochzählende Nummer irgendwie anders, weil es keine ID mehr ist - und dass diese Nummer nicht in der DB steht, sondern beim Auslesen ermittelt wird. Hast Du 'ne Vorstellung, wie aufwändig es ist, beim Erzeugen einer Lücke alle (bis auf einige) Datensätze zu aktualisieren? :-)

Cheatah

[Lude]

Hi,

Die Alternative waere im Beispielfall zwei Datenfelder, also z.B. eine GUID fuer die Eindeutigkeit und eine numerisch hochzaehlende ID fuer die "Eindeutigkeit fuer die Benutzer".

Ja. Nur dass die GUID ID heißt und die hochzählende Nummer irgendwie anders, weil es keine ID mehr ist - und dass diese Nummer nicht in der DB steht, sondern beim Auslesen ermittelt wird. Hast Du 'ne Vorstellung, wie aufwändig es ist, beim Erzeugen einer Lücke alle (bis auf einige) Datensätze zu aktualisieren? :-)

ich habe zwar nicht ganz verstanden, welche Dummheiten mir da wieder zugetraut werden, aber sicherlich bin ich missverstanden worden.

Die o.g. Alternative ist OK. Die GUID heistt immer noch GUID und die ID ist immer noch eine ID. Man kann ja durchaus zwei IDs einem Datensatz zuordnen. Diese Nummer (ID) "steht" natuerlich in der DB.

"Luecken" bei den IDs entstehen grundsaetzlich (bei Systemfehlfunktionen oder durch  Loeschung) und die aufwändige Schliessung dieser sind m.E. kein Thema.

Aber wahrscheinlich hast Du was ganz anderes gemeint...   ;-)

Gruss,
Lude

[Cheatah]

Hi,

Die o.g. Alternative ist OK. Die GUID heistt immer noch GUID und die ID ist immer noch eine ID.

nein, ist sie nicht - es sei denn, Du betrachtest sie nur zu einem einzelnen Zeitpunkt. Darüber hinaus ist sie veränderbar und somit keine ID mehr. Die GUID hingegen ist eine ID und sollte somit idealerweise auch so heißen. Du kannst sie zwar auch "Hans" nennen, wenn Dir danach ist, aber besser ist es, wenn man für den(!) Identifier auch den typischen Namen "ID" wählt.

Man kann ja durchaus zwei IDs einem Datensatz zuordnen.

Man kann vieles, aber es gibt immer nur _den_ Identifier. Dieser kann natürlich aus mehreren Spalten bestehen.

"Luecken" bei den IDs entstehen grundsaetzlich (bei Systemfehlfunktionen oder durch  Loeschung) und die aufwändige Schliessung dieser sind m.E. kein Thema.

Meinst Du damit, man solle es _nicht_ machen, oder meinst Du, es sei kein Problem, dies zu machen? Ersterem stimme ich zu ;-) mit der Konsequenz, dass eine entsprechende Spalte auch keinen Sinn mehr macht - die (eine) ID reicht aus. Ansonsten hättest Du nämlich zwei weitgehend identische Spalten, die vielleicht in einigen (oder von mir aus auch allen) Fällen um wenig differieren.

Aber wahrscheinlich hast Du was ganz anderes gemeint...   ;-)

Tja, ich will nicht ausschließen, dass wir hier irgendwie aneinander vorbei reden ... :-)

Cheatah

[Lude]

Hi,

Man kann ja durchaus zwei IDs einem Datensatz zuordnen.

Man kann vieles, aber es gibt immer nur _den_ Identifier. Dieser kann natürlich aus mehreren Spalten bestehen.

nur noch ein kleiner "Nachtrag". Es gibt immer nur ein Identifikationsdatenfeld (bzw. etwas Zusammengesetztes) je Identifikationssystem. Es spricht nichts dagegen einen Datensatz in mehreren Identifikationssystemen zu verwalten. Wenn der in der Realitaet vorgefundene Sachverhalt nur so abzubilden ist, muss man das auch tun.

Gruss,
Lude

PS: Hab' ich doch recht gehabt!   ;-)

[Klaus Mock]

Hallo,

Es spricht nichts dagegen einen Datensatz in mehreren Identifikationssystemen zu verwalten.

Wobei es wichtig ist zu beachten, dass dann jedes dieser 'Identifikationssysteme' unveränderlich sein muß, spätestens wenn andere Informationen darauf referenzieren, ob in einem geschlossenen System, z.B. eine Datenbank, oder von außerhalb.

Wenn der in der Realitaet vorgefundene Sachverhalt nur so abzubilden ist, muss man das auch tun.

Mehrere eindeutige Identifikationen machen imho nur dann Sinn, wenn verschiedenartige Referenzen notwendig sind (beispiel DB-interne ID und eindeutiger Name für das menschliche Auge). Aber dann sollte auch keine dieser Felder jemals abgeändert werden können.

Grüße
  Klaus

[Cheatah]

Hi,

Mehrere eindeutige Identifikationen machen imho nur dann Sinn, wenn verschiedenartige Referenzen notwendig sind (beispiel DB-interne ID und eindeutiger Name für das menschliche Auge).

was dann wiederum ein typischer Fall für eine 1:n-Tabelle, (mindestens) bestehend aus einem Key und einer ID, ist. Gerade heute habe ich so eine angelegt :-) Allerdings tendiere ich dazu, nur die ID als Identifier anzusehen, der den Key als Übersetzung besitzt - auch wenn dieser ebenfalls Unique ist.

Aber dann sollte auch keine dieser Felder jemals abgeändert werden können.

Das haben Identifier so an sich :-)

Cheatah

[Lude]

Hi,

was dann wiederum ein typischer Fall für eine 1:n-Tabelle, (mindestens) bestehend aus einem Key und einer ID, ist.

zwischen den mehreren Identifikationsdatenfeldern eines Datensatzes besteht (idealerweise ;-) eine "1:1"-Beziehung.

Gruss,
Lude

[Cheatah]

Hi,

was dann wiederum ein typischer Fall für eine 1:n-Tabelle, (mindestens) bestehend aus einem Key und einer ID, ist.
zwischen den mehreren Identifikationsdatenfeldern eines Datensatzes besteht (idealerweise ;-) eine "1:1"-Beziehung.

klar. Mit 1:n meinte ich, dass irgendeine Tabelle sich 1:n auf die Tabelle bezieht, die 1:1 den nummerischen zum menschenlesbaren Identifier bzw. umgekehrt auflöst :-)

Cheatah

[Cheatah]

Hi,

Es spricht nichts dagegen einen Datensatz in mehreren Identifikationssystemen zu verwalten.

nun ja - der höhere Organisations- und Verwaltungsaufwand spricht dagegen. Darüber hinaus:

PS: Hab' ich doch recht gehabt!   ;-)

Offenbar :-)

Cheatah