sprechender Primärschlüssel 8)

[Sharky]

Zitat:

Zitat von Hansa

... auf die Idee gekommen, so einen string-PK zu benutzen ? ....

Wie so ist das den ein string-pk? Wie schon erwähnt handelt es sich doch um eine GUID.

[Jasocul]

Ich denke, wenn man die einzelnen Blöcke nicht in Dezimalzahlen umrechnen will, muss man es als String speichern.

[Hansa]

Das ist ja alles schön und gut. Was ich nur nicht verstehe, das ist, wie man so eine "sprechende Nummer" zum PK machen kann. Bzw. sogar zum einzigen Key. Was hindert einen denn dran, zuerst einmal eine ID als PK zu vergeben und dann noch ein Feld mit der komischen Nr. Das ist doch genau das, mit was Mabuse schon kämpfen mußte. Wenn ich einen Artikel habe und 100 Kunden haben dafür Preise hinterlegt. Dann ist es doch IMHO Leichtsinn, die Artikel-Nr. in der DB zu speichern, also als PK. Die ID dient doch gerade zum Entkoppeln von abhängigen Tabellen.

P.S.: Ah ja, verschoben. Und ich weiß, wie es hier hin gelangt ist. War in dem Klatsch und Tratsch-Thread und hatte "neues Thema" angeklickt. 8)

[Sharky]

Zitat:

Zitat von Jasocul

Ich denke, wenn man die einzelnen Blöcke nicht in Dezimalzahlen umrechnen will, muss man es als String speichern.

Dies ist ja nur die Darstellung einer GUID. Diese ist eigentlich nur eine 128 Bit Zahl.

[Jasocul]

Zitat:

Zitat von Sharky

Zitat:

Zitat von Jasocul

Ich denke, wenn man die einzelnen Blöcke nicht in Dezimalzahlen umrechnen will, muss man es als String speichern.

Dies ist ja nur die Darstellung einer GUID. Diese ist eigentlich nur eine 128 Bit Zahl.

Stimmt auffallend. :oops: :wall:
Aber wenn der DB-Designer das nicht weiß, dann nimmt er Strings. :mrgreen:
Ich habe schon Schlimmeres erlebt. :roll:

[Sharky]

Zitat:

Zitat von Jasocul

... dann nimmt er Strings....

Das Problem ist das die DBSM (die ich kenne) keinen GUID-Typ im eigentlichen Sinne kennen.
MS-SQL z.B. kennt zwar den Feldtyp uniqueidentifier. Dieser wird aber intern als ein String aus 32 Zeichen behandelt wenn ich es richtig gelesen hab.

BTW: Delphi kennt den VariablenTyp : TGUID

Aber das ist ja eigentlich nicht das Thema des Threads.

Grundsätzlich denke ich das man mit einem Integer als PK am besten fährt. Aber wenn es zum Beispiel wie von MaBuSE angesprochen um die Sync. von verschiedenen Servern/Datenbanksystemen geht hat die GUID oder andre "sprechende" Schlüsseln natürlich seine Vorteile und auch seine Daseinsberechtigung.

Entscheidend ist die Frage: Wie wirkt sich deren Verwendung auf Geschwindigkeit der Anwendung aus?
Wenn ich z.B eine weltweite Erfassung von Daten mache. Diese Daten teilweise auf verschiedenen Servern und teilweise in lokalen DBs gespeichert werden und meine Abfrage später keine großen Verknüpfungen benötigen bin ich mit der Verwendung einer GUID sicher besser beraten als die Verwendung von Integer-IDs.

[Hansa]

Meiner Ansicht nach hat eine GUID in dem Zusammenhang absolut nichts zu suchen. Ganz davon abgesehen, daß sie viel zu lang ist. Deshalb wohl auch die -. Mabuse, ging es bei Dir nur um die eindeutige Identifikation eines Standortes, oder was ? Wenn ich MAC-Adressen, GUIDs usw. in der DB verbaue, dann ist man nämlich schnell wieder am Anfang !

[eddy]

Hallo Leute,

ich glaube, mir ist etwas entgangen!!

Was ist ein "sprechender Primärschlüssel" ??

Meine Primärschlüssel heißen alle ID und sind vom Typ AutoInc und damit es keine Probleme mit zermatschten Datenbanken gibt (insbesondere mit Paradox-DB) habe ich immer noch einen <Name>ID vom Typ Integer eingeführt, die die Verbindung mit anderen Datenbanken herstellt und <Name> eine Zeichenkette ist, die etwas mit der verwendeten Datenbank zu tun hat (Art = Artikel, Auf = Auftrag usw.)
Die zweite ID bleibt auch dann erhalten, wenn es mal wieder eine Paradox-DB zerlegt hat und sich die Daten nur durch kopieren der einzelnen (unbeschädigten) Datensätzen reparieren ließ, wodurch aber alle ID's vom Typ AutoInc neu erzeugt werden und nicht zwangsläufig mit den originalen übereinstimmten.


mfg
eddy

[Hansa]

Zitat:

Zitat von eddy

...ich glaube, mir ist etwas entgangen!! ...

So ist es. Ein solches Konstrukt ist z.B. eine Art.-Nr. in die man sämtlichen Schwachsin reinpackt. Also PLZ, Warengruppe, Lieferant usw.

[Jasocul]

Es gibt ja auch nichts gegen sprechende Schlüssel einzuwänden (an die Schreibweise muss ich mich wirklich noch gewöhnen :roll: ). Der PK sollte das aber nicht sein.
Ich benutze auch sprechende Schlüssel, die aus mehreren Feldern zusammengesetzt sind. Da wird aber kein einzelnes Feld draus gemacht, sondern einfach ein zusammengesetzter Index gebastelt, der i.d.R. auch noch Unique ist. Aber der PK ist bei mir immer Integer und hat mit dem sprechenden Schlüssel nichst zu tun. Die Relationen zwischen den Tabellen werden auschließlich über den PK definiert, niemals über den sprechenden Schlüssel. Wer es anders macht, sollte erschossen werden. :mrgreen: