Laden...

Primary Keys

Erstellt von chanderegg vor 11 Jahren Letzter Beitrag vor 11 Jahren 1.449 Views
C
chanderegg Themenstarter:in
101 Beiträge seit 2008
vor 11 Jahren
Primary Keys

verwendetes Datenbanksystem: SQLServer2008

Hallo zusammen

Ich möchte eine bestehende Datenbank optimieren. Dazu erstelle ich als erstes Primary Keys.
Nun habe ich eine Tabelle mit 3 Spalten, welche alle Unique sind. Ist es nun besser den Primary Key auf eine Spalte zu definieren und über die beiden anderen einen Index zu legen oder soll ich den Primary Key über alle 3 Spalten definieren?

Vielen Dank für Eure Hilfe
chanderegg

1.552 Beiträge seit 2010
vor 11 Jahren

Hallo chanderegg,

ich erstelle in diesen Fällen immer einen Primary Key auf einer Spalte und dann auf den einen Unique Key über die drei Spalten. Andernfalls müsstest du in Tabellen welche auf diese Tabelle referenzieren, ebenfalls drei Spalten einfügen um den Datensatz identifizieren zu können. Diesen Speicherplatz welcher der Unique Index benötigt wird dadurch kompensiert, dass du dann bei referenzierenden Tabellen anstelle von drei Spalten nur eine Spalte benötigst.

Gruß,
Michael

Mein Blog
Meine WPF-Druckbibliothek: auf Wordpress, myCSharp

106 Beiträge seit 2011
vor 11 Jahren

Hallo chanderegg,

aus deiner Beschreibung ist leider nicht viel raus zu lesen. Welchen Sinn würdest du denn darin sehen einen PK aus 3 verschiedenen Schlüsseln zusammen zu bauen?
Grundsätzlich ist ein PrimaryKey ein durchlaufender Zähler, ganz unabhängig für welche inhaltlichen Daten er benutzt wird.

MfG
Rabban

F
115 Beiträge seit 2012
vor 11 Jahren

Hi,

als erstes ist die Frage wichtig, ob alle drei Spalten für sich unique sind, oder erst die Kombination der drei. Dann stellt sich die Frage, was Du eingentlich ereichen möchtest. Sicherstellen, dass die Kombination der Werte einzigartig ist (dann einen Unique Constraint / Index auf die drei Felder), oder tatsächlich einen Primärschlüssel für die Referenzierung aus einer anderen Tabelle erzeugen (dann ist eine forlaufende ID ganz gut).

Ach ja: das ist m.E. der Sinn eines PrimaryKey: er dient als ForeignKey in einer anderen Tabelle. Das sieht Wikipedia auch so:

Schlüssel (Datenbank)

Wenn man sich dafür entscheidet kann man auch weitere Constraints auf die referentielle Integrität auf der DB erzeugen, was Vor- und Nachteile hat. Dafür ist natürlich interessant, was Du als Optimierung ansiehst (Datenqualität, Lese- oder Schreibgeschwindigkeit, ect.)

Gruß
f_igy

4.221 Beiträge seit 2005
vor 11 Jahren

ich erstelle in diesen Fällen immer einen Primary Key auf einer Spalte und dann auf den einen Unique Key über die drei Spalten. Andernfalls müsstest du in Tabellen welche auf diese Tabelle referenzieren, ebenfalls drei Spalten einfügen um den Datensatz identifizieren zu können. Diesen Speicherplatz welcher der Unique Index benötigt wird dadurch kompensiert, dass du dann bei referenzierenden Tabellen anstelle von drei Spalten nur eine Spalte benötigst.

Dies mag in vielen Fällen eine gute Lösung sein. Aber diese Lösung hat auch Nachteile:

  • Beim speichern auf der 1-Tabelle müssen zwei Indizes angepasst werden (dauert allenfalls länger).
  • wenn Du von der n-Tabelle lesen willst und als Input nur die Felder hast welche auf der 1-Tabelle den Unique Key builden, dann musst Du über die Parent-Table joinen.

Dies sollte beim Design berücksichtigt werden (Anzahl Schreibvorgänge / welche Daten liegen wann und wie vor). usw.

Gruss
Programmierhans

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...