DB-Feld im Klartext als Schlüssel oder besser IDs ?

[Hansa]

Hi,

es geht darum, ob IDs verwendet werden sollen, oder ob ein Feld der DB als Primary Key verwendet werden soll. Z.B. Kundennr. als Primary-Key, anstatt jedem Datensatz eine ID zu verpassen und nur darüber Verknüpfungen herzustellen.

Was spricht für das eine oder das andere ? Um es Vorweg zu nehmen : bei mir hätte sogar eine Tabelle mit einem einzigen relevanten Feld trotzdem noch eine vom User nicht manipulierbare ID.

[marabu]

Hallo Hansa,

dieses Thema, das dich ja in immer kürzeren Zeitabständen bewegt, leidet in jeder Diskussion an einer klaren Begriffsbestimmung. Du sprichst von ID als Synonym für einen primary key, aber ID steht salopp für identifier und entspricht dann in unseren Breiten der Nummer nach DIN 6763. Es ist nicht gut, wenn ständig Begriffe aus der Datenbank-Technik (Schlüssel) mit solchen aus der Datenbank-Anwendung (Nummer) vermischt werden. (Wirtschafts-)Informatiker unterscheiden klar zwischen Schlüsseln und Nummern. Ist ja auch beides seit etwa 20 Jahren gut beschrieben, Schlüsssel in der relational theory nach Codd und Nummern in der DIN.

Genauso, wie es Gründe zur Aufhebung bestimmter Normalformen, zur kontrollierten Einführung von Redundanz, gibt, genauso mag es ökonomische Gründe geben, warum einer auf einen surrogate key verzichtet, wenn er geeignete candidate keys kennt.

Da mag es lookup tables mit weniger als 10 Tupeln geben - z.B. ein dictionary für das Attribut Geschlecht, zwei Tupel (m, männlich) und (w, weiblich). Der Datenbank-Hersteller hat schon seinen rowid dazugepackt, ob du es willst oder nicht. Jetzt packst du deinen noch dazu. Es gibt Menschen die tragen Hosenträger und Gürtel. Ich verurteile das nicht. Wer sich falsch entscheidet, der bekommt halt Prügel.

Grüße vom marabu

[Jasocul]

Zitat:

Zitat von marabu

Du sprichst von ID als Synonym für einen primary key, aber ID steht salopp für identifier und ...

Das habe ich auch schon im letzten Thread versucht zu erklären.

Zitat:

Zitat von marabu

Da mag es lookup tables mit weniger als 10 Tupeln geben - z.B. ein dictionary für das Attribut Geschlecht, zwei Tupel (m, männlich) und (w, weiblich). Der Datenbank-Hersteller hat schon seinen rowid dazugepackt, ob du es willst oder nicht. Jetzt packst du deinen noch dazu.

Ich denke mal, bei den Beispielen wäre es wirklich übertrieben eine eigene ID zu verwenden. Ich habe zwar im letzten Thread gesagt, dass ich immer eine ID verwende, aber bei solchen Tabellen (wenn man es überhaupt so nennen mag), vernachlässige ich das dann auch schon mal.

[Hansa]

Marabu, mich bewegt gar nichts in immer schnelleren Abständen. Das ist eben eine Diskussion. Die habe ich jetzt verlagert, weil sie auf ein Randthema kam. Und jetzt fange bitte nicht noch mit DIN usw. an. 8) Dann sage ich eben "automatisch vom Programm zu vergebende interne Datensatznummer" statt ID. Ist Dir das lieber ?

Ich will ja auch nur wissen, wer das nicht so macht und warum. Es geht im Prinzip auch eher um Schlüssel. Das Primary ist auch eher sekundär zu sehen.

[MaBuSE]

Zitat:

Zitat von Hansa

Das ist eben eine Diskussion. Die habe ich jetzt verlagert, weil sie auf ein Randthema kam.

Das Randthema in der Diskussion "sprechender Primärschlüssel" war "GUID als Primärschlüssel".
Die Diskussion kann man hier nachlesen: http://www.delphipraxis.net/internal...ct.php?t=59862

[MaBuSE]

Zitat:

Zitat von Hansa

Dann sage ich eben "automatisch vom Programm zu vergebende interne Datensatznummer" statt ID. Ist Dir das lieber ?

Ich würde das wenn möglich ins Backend setzen. Also:
"automatisch vom SQL-Server zu vergebender interne Datensatznummer"
Im MS-SQL Server ist das imho eine GUID.

Falls Du folgendes meinst:
"automatisch vom SQL-Server zu vergebender Primärschlüssel"
Dort würde ich in bestimmten Situationen (siehe letzte Diskussion) dem "autoinc Integer" eine GUID vorziehen.

Zitat:

Zitat von Hansa

Das Primary ist auch eher sekundär zu sehen.

Wozu brauchst Du einen "automatisch vom Programm zu vergebenden Sekundärschlüssel" ??? :roll:

[marabu]

Hallo MaBuSE,

Zitat:

Zitat von MaBuSE

"automatisch vom SQL-Server zu vergebender interne Datensatznummer"
Im MS-SQL Server ist das imho eine GUID.

die interne Datensatznummer hat immer einen ordinal type - du verwechselst das vielleicht mit einer ROWGUIDCOL, die eine globale Eindeutigkeit über die NewID() gewährleisten soll. Eine solche Spalte ist aber nicht intern, sondern wird von dir beim Ableiten des physischen (aus dem konzeptuellen) Datenmodell hinzugefügt. Hansa scheint mir stets von einer IDENTITYCOL (ms sql server lingo) zu schreiben. Auch die ist nicht intern, sondern wird vom DB-Designer modelliert.

Zitat:

Zitat von MaBuSE

"automatisch vom SQL-Server zu vergebender Primärschlüssel"
Dort würde ich in bestimmten Situationen (siehe letzte Diskussion) dem "autoinc Integer" eine GUID vorziehen.

Bei mir kommt ein GUID PK nur für verteilte Datenbanken in Frage und das auch nur unwillig, solange ich flächendeckend keine 64bit Prozessoren vorfinde.

marabu

[MaBuSE]

Zitat:

Zitat von marabu

Zitat:

Zitat von MaBuSE

"automatisch vom SQL-Server zu vergebender interne Datensatznummer"
Im MS-SQL Server ist das imho eine GUID.

die interne Datensatznummer hat immer einen ordinal type - du verwechselst das vielleicht mit einer ROWGUIDCOL, die eine globale Eindeutigkeit über die NewID() gewährleisten soll. Eine solche Spalte ist aber nicht intern, sondern wird von dir beim Ableiten des physischen (aus dem konzeptuellen) Datenmodell hinzugefügt. Hansa scheint mir stets von einer IDENTITYCOL (ms sql server lingo) zu schreiben. Auch die ist nicht intern, sondern wird vom DB-Designer modelliert.

Das mag sein, ich arbeite momentan nicht mit ms-sql Servern. ;-)
Bei Oracle ist die rowid definitiv keine GUID.

Zitat:

Zitat von marabu

Zitat:

Zitat von MaBuSE

]"automatisch vom SQL-Server zu vergebender Primärschlüssel"
Dort würde ich in bestimmten Situationen (siehe letzte Diskussion) dem "autoinc Integer" eine GUID vorziehen.

Bei mir kommt ein GUID PK nur für verteilte Datenbanken in Frage und das auch nur unwillig, solange ich flächendeckend keine 64bit Prozessoren vorfinde.

Dito, verteilte Datenbanken meinte ich mit "bestimmte Situationen (siehe letzte Diskussion)" Ich arbeite meist mit dem guten alten integer, der automatisch um eins erhöht wird. (Ist vieleicht etwas altmodisch, funktioniert aber).
Ich habe bisher nur in einem Projekt die GUID als PK gebraucht.
Dort aber konsequenterweise in jeder Tabelle als PK. Alles anderen "Pseudo-Schlüssel-Felder" waren nur "Matchcodes" (Kundenr, Artikelnr, ...) die nicht zur Verknüpfung genutzt wurden.

[Sharky]

Ich handhabe es eigentlich genau wie MaBuSE,

wenn immer es geht benutze ich für den PK ein AutoInc-Feld(Integer).
Ich hatte aber ein/zweimal den Fall das ich eine GUID als PK verwendet habe. In diesen Fällen hätte der Aufwand dies auf einem anderen Weg zu lösen in keinem Verhältniss zum Nutzen gestanden. Vor allem weil es dort fast keinen geschwindigkeits unterschied gemacht hat.

Sobald es aber einmal DBMS gibt welche das sauber handhaben könnne (Hardware die es kann). Werde ich mit viel Vergnügen nur noch GUIDs verwenden.

[Robert_G]

Kleines OT:

Zitat:

Zitat von MaBuSE

Bei Oracle ist die rowid definitiv keine GUID.

Sie ist ein GlobalUniqueIdentifier innerhalb der DB. Du findest dort die Position des Datensatzes auf der HDD, Tablespace,...
Das dürfte dazu führen, das es mit höherer Wahrscheinlichkeit die gleiche RowID in einer anderen DB auf einer anderen Maschine gibt... Es ist sehr unwahrscheinlich, dass es die gleiche RowId in einer anderen Instanz auf der gleichen Maschine/Cluster gibt. (Ist mir jedenfalls noch nie aufgefallen ;) )