Danke fuer diese intersante erklaerung!

Gruss

Roman Pittroff
Consulting
Bangkok, Thailand


-----Original Message-----
From: Joachim van de Bruck [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, October 25, 2001 10:28 PM
To: [EMAIL PROTECTED]
Subject: [aspdedatabase] AW: RE: AW: RE: AW: RE: AW: LastID von AddNew


Hallo!

> Hmmm der primary-key soll ja nicht durch die guid verdraengt werden. 
> sondern der wert des primary-key. Das der table einen primary-key ist 
> schon klar. Oder verstehe ich da was falsch wenn ja was? :-)

Ein logischer Primary-Key ist die Menge der Spaltenwerte, die ben�tigt
wird, um einen Datensatz eindeutig zu identifizieren.

Bei einer Tabelle mit Adressen kann das nicht allein der Nachname sein,
da es je unterschiedliche Personen mit gleichem Nachnamen geben kann. Es
reicht auch nicht aus, den Vornamen hinzu zu nehmen. �blicherweise
verwendet man als logischen Prim�rschl�ssel so etwas wie 10 Stellen
Nachname + 5 Stellen Vorname plus 5 Stellen Stra�enname + PLZ plus
Hausnummer. Einfacher w�re z. B. die Personalausweisnummer. Ohne einen
logischen Prim�rschl�ssel kann man bei verteilten Datenbanken
Doppelerfassungen nicht erkennen und also nicht vermeiden.

Im Gegensatz dazu wird die Replikations-ID oder die GUID verwendet, um
verschiedene Versionen eines physischen Datensatzes zusammenf�hren zu
k�nnen. Ohne GUID w�rde eine Namens�nderung in einer Datenbank nicht in
den anderen nachgeholt werden k�nnen, weil sich Daten des
Prim�rschl�ssels ja auch ver�ndern k�nnen.

Dar�ber hinaus gibt es eine DSN (Datensatznummer) oder eine RowID oder
kurz "id", die man verwendet, um Datens�tze innerhalb einer Datenbank
eindeutig zu identifizieren, zum Beispiel, um Daten�nderungen zur�ck zu
schreiben oder mehrere tabellen zu verkn�pfen. Der logische
Prim�rschl�ssel taugt hier nicht, da ja auch gerade der ver�ndert werden
kann. Die Replikations-ID w�rde funktionieren, ist aber doch insgesamt
aufwendiger als eine eigene, kurze RowID. Insofern w�rde ich die
L(ocal)UID, die klassische "id", der GUID gerade im Hinblick auf
Verkn�pfungen vorziehen, zumal ADO die AutoIncrement-ID sehr gut
unterst�tzt. Hat man aber grunds�tzlich verteilte Datenbanken, kann man
auch auf die RowID verzichten, Verkn�pfungen sind aber performanter mit
der kleinen RowID.

Hm, ich glaube, Du hast das richtig verstanden, oder?

Freundliche Gr��e
Joachim van de Bruck




> 
> Gruss
> 
> Roman Pittroff
> Consulting
> Bangkok, Thailand
> 
> -----Original Message-----
> From: Joachim van de Bruck [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 25, 2001 9:50 PM
> To: [EMAIL PROTECTED]
> Subject: [aspdedatabase] AW: RE: AW: RE: AW: LastID von AddNew
> 
> 
> Hallo!
> 
> > :-)
> > >Aber wieso nicht ein normales autoincrement?
> > Ist einfach geschmacksache so macht asp den schluessel und speziell 
> > bei componenten brauch ich die guid nicht zurueckgeben.
> 
> Eine GUID braucht man ausschlie�lich f�r Replikationen oder generell
f�r
> verteilte Datenbanken. Und selbst f�r die Replikation braucht man noch

> zus�tzlich einen logischen Primary-Key, um Dubletten zu vermeiden.
Eine
> GUID ersetzt also nie den Primary-Key.
> 
> > >Abgesehen davon kann man dann auch keinen PrimaryKey setzen ....
> > Das stimmt aber nicht solange ich bei unique PrimaryKey keine 
> > doppelten guids mitgebe.
> 
> Es ist sehr sinnvoll, wenn die Datenbank ihren eigenen Primary-Key 
> verwaltet. Eine GUID ist keine Alternative.
> 
> Freundliche Gr��e
> Joachim van de Bruck
> 
> 
> 
> | [aspdedatabase] als [EMAIL PROTECTED] subscribed 
> | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv Sie 
> | k�nnen sich unter folgender URL an- und abmelden: 
> | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp


| [aspdedatabase] als [EMAIL PROTECTED] subscribed 
| http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv Sie 
| k�nnen sich unter folgender URL an- und abmelden: 
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp


| [aspdedatabase] als [email protected] subscribed
| http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp

Antwort per Email an