AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi DB-Feld im Klartext als Schlüssel oder besser IDs ?
Thema durchsuchen
Ansicht
Themen-Optionen

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

Ein Thema von Hansa · begonnen am 27. Jul 2005 · letzter Beitrag vom 28. Jul 2005
Antwort Antwort
Seite 1 von 2  1 2      
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#1

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

  Alt 27. Jul 2005, 12:07
Datenbank: allgemein • Zugriff über: egal
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.
Gruß
Hansa
  Mit Zitat antworten Zitat
marabu

Registriert seit: 6. Apr 2005
10.109 Beiträge
 
#2

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 12:48
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
  Mit Zitat antworten Zitat
Benutzerbild von Jasocul
Jasocul

Registriert seit: 22. Sep 2004
Ort: Delmenhorst
1.355 Beiträge
 
Delphi 11 Alexandria
 
#3

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 12:56
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 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.
Peter
  Mit Zitat antworten Zitat
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#4

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 13:05
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.
Gruß
Hansa
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

Registriert seit: 23. Sep 2002
Ort: Frankfurt am Main (in der Nähe)
1.840 Beiträge
 
Delphi 10 Seattle Enterprise
 
#5

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 13:10
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 - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

Registriert seit: 23. Sep 2002
Ort: Frankfurt am Main (in der Nähe)
1.840 Beiträge
 
Delphi 10 Seattle Enterprise
 
#6

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 13:19
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 von Hansa:
Das Primary ist auch eher sekundär zu sehen.
Wozu brauchst Du einen "automatisch vom Programm zu vergebenden Sekundärschlüssel" ???
(°¿°) MaBuSE - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)
  Mit Zitat antworten Zitat
marabu

Registriert seit: 6. Apr 2005
10.109 Beiträge
 
#7

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 14:30
Hallo MaBuSE,

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 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
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

Registriert seit: 23. Sep 2002
Ort: Frankfurt am Main (in der Nähe)
1.840 Beiträge
 
Delphi 10 Seattle Enterprise
 
#8

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 14:39
Zitat von marabu:
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 von marabu:
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.
(°¿°) MaBuSE - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)
  Mit Zitat antworten Zitat
Benutzerbild von Sharky
Sharky

Registriert seit: 29. Mai 2002
Ort: Frankfurt
8.252 Beiträge
 
Delphi 2006 Professional
 
#9

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 19:11
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.
Stephan B.
"Lasst den Gänsen ihre Füßchen"
  Mit Zitat antworten Zitat
Robert_G
(Gast)

n/a Beiträge
 
#10

Re: DB-Feld im Klartext als Primärschlüssel oder besser IDs

  Alt 27. Jul 2005, 19:29
Kleines OT:
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 )
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:52 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz