AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Datenbank Primary Key

Ein Thema von JoltinJoe · begonnen am 26. Jun 2010 · letzter Beitrag vom 30. Jun 2010
Antwort Antwort
Seite 3 von 4     123 4      
Benutzerbild von fkerber
fkerber
(CodeLib-Manager)

Registriert seit: 9. Jul 2003
Ort: Ensdorf
6.723 Beiträge
 
Delphi XE Professional
 
#21

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 08:03
Hi!

Du sollst keinen Trigger auf Feld_A setzen. Ein Trigger ist einfach eine Funktion, die z.B. bei jedem Insert aufgerufen wird (in dem Fall hier vor dem Insert - ein sog. before-Trigger)

Machen wir mal ein prakt. Beispiel:
Du hast eine Tabelle "Adressdaten" mit den Feldern "Strasse, Hausnummer, PLZ, Ort, Land" - nach den Anforderungen deines Systems sind alle diese Felder nötig, um eine Adresse eindeutig zu identifizieren. Du müsstest also einen PK definieren, der über alle 5 Felder geht.
(Würdest du z.B. nur Strasse+Hausnummer nehmen würden diese 2 Einträge nicht gehen:
"Hauptstr., 22, 12345, Testort, Testland" und "Haupstr., 22, 98765, Musterstadt, Musterland".

Somit hast du jetzt einen ziemlich unhandlichen PK in der Hand.
Sagen wir mal, du hast eine Tabelle Person [Vorname, Nachname] (auch beide zusammen als PK) und willst der Person eine Adresse zuordnen - das Ganze als n:m-Beziehung (also mehrere Personen an einer Adresse, mehrere Adressen pro Person), dann musst du in der Tabelle, die diese Beziehung ausdrückt, die Schlüssel der beiden beteiligten Tabellen haben. D.h. du hast hier eine Mega-Tabelle mit 7 Attributen.

So, würdest du sowohl bei Person wie auch bei Adresse einen künstlichen PK erzeugt hast (fortlaufende Nummerierung), dann identifiziert das eindeutig. D.h. du brauchst in der Beziehunstabelle nur 2 Felder, die ID von Person und die ID von Adresse.

Ich hoffe, ich konnte etwas Licht ins Dunkle bringen.


Liebe Grüße,
Frederic
Frederic Kerber
  Mit Zitat antworten Zitat
JoltinJoe

Registriert seit: 26. Jun 2010
29 Beiträge
 
Delphi 7 Enterprise
 
#22

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 08:17
Jo alles klar das hab ich kapiert

Nochmal zu der Frage "Warum lassen sich Daten mit einem PK schneller abrufen?" : Das macht doch nur Sinn wenn in der Abfrage der abzurufende Schlüssel bekannt ist ?
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.858 Beiträge
 
Delphi 11 Alexandria
 
#23

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 09:40
Das zusätzlich Feld wird zum PK. Das hat den Vorteil, dass die Werte im FELD_A später geändert werden können ohne dass Fremdschlüsselbeziehung zerstört werden bzw. angepasst ´werden müssten.
Markus Kinzler
  Mit Zitat antworten Zitat
idefix2

Registriert seit: 17. Mär 2010
Ort: Wien
1.027 Beiträge
 
RAD-Studio 2009 Pro
 
#24

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 11:11
Es geht da nicht um "schneller".
Der PK muß Unique sein. Auch wenn im Moment iregend eine Feldkombination unique ist, muß das nicht immer so bleiben. Beispiel:

Du hast einen Unique Key: Name, Vorname, Wohnort.
Dein Programm funktioniert wunderbar, und greifst überall in Deinem Programm mit diesem primary Key auf die Tabelle zu. Jetzt kommst Du irgendwann drauf, dass es in Berlin zwei verschiedene Hans Meier gibt, die Du in Deiner Datenbank verwalten musst, und brauchst deshalb für die Eindeutigkeit noch zusätzlich das Feld Strasse. Dann musst Du überall in Deinem Programm in allen Abfragen den Zugriff auf die Datenbank anpassen, alle Fremdschlüssel, die in anderen Tabellen auf diese Tabelle verweisen, müssen geändert werden usw.
Wenn Du aber von vorneherein ein künstliches Feld als PK verwendest, bedeutet so eine Änderung nur minimalen Aufwand.
  Mit Zitat antworten Zitat
Hansa

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

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 14:30
Jo alles klar das hab ich kapiert
Sicher ? Noch ein Beispiel :

Szenario 1 (ohne IDs) : folgende Tables werden für irgendein Programm gebraucht : Artikel, Lager, Statistik, Rechnung. Den 3 letzten müssen dann natürlich Artikel zugeordnet werden. OK, man nimmt die Art.Nr. Da stehen also jetzt in der Lager-,Statistik- und Rechnungstabelle z.B. Datensätze mit artnr = 100. Der User verspürt aber plötzlich Lust, für den entsprechenden Artikel artnr = 1000 zu verwenden. Was ist zu tun ? Die 3 vom Artikel abhängigen Tabellen müssen komplett nach artnr = 100 durchsucht werden und an allen Fundstellen durch artnr = 1000 ersetzt werden. Im Prinzip kann erst wenn alle auf 1000 gesetzt sind der entsprechende Artikel selbst von artnr = 100 auf 1000 geändert werden.

Szenario 2 (mit IDs) : Artikel kriegt zusätzlich eine ID. Und diese wird automatisch per Generator/Trigger hochgezählt. Dann ist sie sofort eindeutig. Auch die drei anderen Tabellen erhalten vorsichtshalber eine ID und auch (und jetzt kommt das Wichtige) eine IDart. Also steht da nicht mehr ein Feld artnr = 100, sondern das Feld IDart = 95 (bspw.). Die 95 stammt von dem Artikel mit Nr. 100, der die ID = 95 hat. Was muss hier jetzt bei Änderung der Art.Nr. von 100 auf 1000 gemacht werden ? Einfach das Feld Art.Nr. von 100 auf 1000 ändern. Das wars. Die 95 bleibt ja, wie sie ist. Für die Rechnung- usw. Tabellen, ist der Artikel dadurch immer noch eindeutig zu lokalisieren. Da braucht überhaupt nichts gemacht zu werden !

Man sieht hier sehr oft weggelassene IDs oder so was wie bereits gesagt : PK für Name und dann noch die Str. mitschleppen usw. Was aber, wenn in einem Haus 2 Meier wohnen ? Ich sage nur : Murphy lässt grüssen. Mal ganz davon abgesehen, dass ein PK aus Name, Strasse, Ort oder womöglich noch mehr viel zu gross wird. ID hätte lediglich 4 Byte.
Gruß
Hansa

Geändert von Hansa (29. Jun 2010 um 14:38 Uhr)
  Mit Zitat antworten Zitat
JoltinJoe

Registriert seit: 26. Jun 2010
29 Beiträge
 
Delphi 7 Enterprise
 
#26

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 15:45
Ja, wie schon erwähnt...das hab ich kapiert.

Ich war nur etwas verwirrt weil, anscheinend ein labersack, mal meinte "wenn du kein pk hast, dann wird es Ewigkeiten dauern einen String in deinem Feld zu finden" ...
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.858 Beiträge
 
Delphi 11 Alexandria
 
#27

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 17:12
Wenn die Tabelle sehr groß ist, kann es schon dauern, wird dieses Feld dann zufällig zum PK, kann es schon schnneller werden ( wenn nicht auf like gesucht wird). Ich glaube aber er hat PK mit Index verwechselt/gleichgesetzt
Markus Kinzler
  Mit Zitat antworten Zitat
JoltinJoe

Registriert seit: 26. Jun 2010
29 Beiträge
 
Delphi 7 Enterprise
 
#28

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 20:07
Hm ja möglicherweise. Aber auf einen Primärschlüssel wird doch automatisch ein Index gelegt? Möglicherweise hat er das verwechselt.
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.619 Beiträge
 
Delphi 12 Athens
 
#29

AW: Datenbank Primary Key

  Alt 29. Jun 2010, 20:10
Jedes PK-Feld wird automatisch indiziert, aber nicht jedes indizierte Feld wird automatisch PK (wie soll das auch funktionieren?).
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
JoltinJoe

Registriert seit: 26. Jun 2010
29 Beiträge
 
Delphi 7 Enterprise
 
#30

AW: Datenbank Primary Key

  Alt 30. Jun 2010, 06:29
Ja, das hat auch keiner behauptet Ich denke ich habe vorerst genug Informationen.. Danke !

bYe
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 4     123 4      


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 18:31 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