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 ;) )

[Hansa]

Ich fasse es nicht. Da macht man einen neuen Thread auf, um von der GUID wegzukommen hat wenig Zeit und dann kommt noch DIN und Robert_G. :lol: Die DP ist echt köstlich. :mrgreen: Manchmal hat es wohl keinen Zweck, ein ernsthaftes Thema zu erörtern. 8)

[Sharky]

Zitat:

Zitat von Hansa

.... Manchmal hat es wohl keinen Zweck, ein ernsthaftes Thema zu erörtern.

Hai Hansa,

das kann aber auch daran liegen das Du

• Nicht genau sagen kannst was Du eigentlich erörtern möchtest
• Bei dem was Du sagst verschiedene Begriffe durch einander wirfst (darum ja marabus verweiss auf die DIN)
• Du fast alles ablehnst was Du nicht kennst und es deshalb als schlecht betrachtest

Ich selber fand den ursprünglichen Thread sehr interessant. Warum genau Du jetzt noch einen zu einem fast gleichen Thema aufmachst verstehe ich nicht so richtig.

Aber da die Themen nun einmal fast gleich sind ist es doch selbsverständlich das auch die selben Argumente gebracht werden bzw. die selben Methoden (unter anderem die Verwendung einer GUID) beschrieben werden.

[marabu]

Hallo Hansa,

Zitat:

Zitat von Hansa

Ich fasse es nicht. Da macht man einen neuen Thread auf, um von der GUID wegzukommen hat wenig Zeit und dann kommt noch DIN und Robert_G.

meinst du mich mit DIN? Es tut mir sehr leid, wenn dein thread einen für dich unerwarteten Verlauf genommen hat. Wenn du von dem GUID wegwolltest, nun ja - du konntest nicht besser fahren als mit diesem thread. Das Maß an Konsens über den Verwendungszweck und die Rahmenbedingungen für einen GUID kann gar nicht größer sein als in diesem thread. Findest du nicht? Und deine andere Absolutposition hat niemand mit Negativkritik bedacht. Was willst du mehr?

Nächtliche Grüße vom marabu

[MaBuSE]

Zitat:

Zitat von Hansa

Ich fasse es nicht. Da macht man einen neuen Thread auf, um von der GUID wegzukommen ... Manchmal hat es wohl keinen Zweck, ein ernsthaftes Thema zu erörtern. 8)

Wieso von der GUID wegkommen, Du spricht in deinem Titel von ID. Schau Dir mal die letzen 2 Buchstaben von GUID an.

Ansonsten schliesse ich mich der Meinung von Sharky und marabu in den letzten 2 Posts an.