[SQL Server 7.0/2000] Index / Constraint?!?!

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo zusammen,
lese mir immer wieder die Online-Hilfe durch, komme aber nicht so wirklich dahinter, in welchem Fall es besser ist einen

  • Create UNIQUE Constraint
    oder einen
  • Create UNIQUE Index
    zu machen.

Momentan verstehe ich das so:
Wenn ich eine „Unique Constraint“ verwende, passt mir der SQL-Server darauf auf, dass der Index „eindeutig“ bleibt.

„Unique Index“ macht das ebenfalls, nur das noch zusätzlich die Suche, vor allem bei grossen Datenmengen, beschleunigt wird.

Ist das im groben Richtig so?!?
sanx from michL

#2

Auch ein UNIQUE CONSTRAINT führt dazu, dass ein Index für dieses Feld angelegt wird.

Eigentlich gibt es m.E. wenig Gründe (bzw.: Möglichkeiten), in einer normalisierten relationalen Datenbank neben dem Primärschlüssel noch weitere eindeutige Indizes in einer Tabelle zu haben!

#3

Auch ein UNIQUE CONSTRAINT führt dazu, dass ein Index für
dieses Feld angelegt wird.

Das habe ich mir schon fast gedacht, das dass so ist. So wie ich das sehe, ist es somit egal, ob ich Index oder Constraint nehme.

Eigentlich gibt es m.E. wenig Gründe (bzw.: Möglichkeiten), in
einer normalisierten relationalen Datenbank neben dem
Primärschlüssel noch weitere eindeutige Indizes in einer
Tabelle zu haben!

Da verstehe ich nicht, was Du mir damit sagen willst?!?

sanx from michL

#4

Da verstehe ich nicht, was Du mir damit sagen willst?!?

Nun, wenn es einen eindeutigen Index in der Tabelle gibt, dann ist der doch automatisch Kandidat für den Primärschlüssel. Es müsste also zwei eindeutige Felder (bzw. Kombinationen von Feldern) in der Tabelle geben, die voneinander funktional unabhängig sind (um die 3NF nicht zu verletzen).

Auf Anhieb fällt mir kein Beispiel für so etwas ein…

#5

Ich stehe eigentlich vor folgendem kleinen Problem/Frage:
Ich habe 3 Felder (String):

  • UData
  • NodeID
  • Class

‚UData‘ darf mehrmals vorkommen.
‚NodeID‘ darf mehrmals vorkommen.
‚Class‘ darf mehrmals vorkommen.

Alle 3 zusammen soll aber einmalig vorkommen.
Des weiteren möchte ich nach allen 3 gleichzeit suchen können (und das möglichst schnell). D.h. ich bekomme dann auch maximal nur einen Datensatz oder eben keinen.

Was ich mich jetzt frage ist, ob ich Index oder Constraint nehmen soll?!?

#6

Und was ist der Primärschlüssel der Tabelle?
Dürfen denn auch Nullwerte vorkommen?
Willst du auch einzeln nach den Feldern suchen?

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#7

Und was ist der Primärschlüssel der Tabelle?

Der Primärschlüssel ist ein anderes numerisches Feld Namens ‚Nr‘, dessen Inhalt ich vergebe.

Dürfen denn auch Nullwerte vorkommen?

Null Nein - Leer, Blanks aber schon.

Willst du auch einzeln nach den Feldern suchen?

Es kann schon vorkommen, dass ich so Abfragen mache wie:
SELECT * FROM tabXXX WHERE UData = ‚aaaa‘;
Wobei mir das nicht so wichtig ist…

Wichtig ist für mich wenn ich ein
SELECT * FROM tabXXX WHERE UData = ‚aaaa‘ AND NodeID = ‚bbbb‘ AND Class = ‚cccc‘;
mache, das es möglichst schnell geht (Vollgas!!!) und das ich dann nur maximal 1nen Datensatz zurück bekomme oder keinen (weil die Kombination aus UData, NodeID und Class ja eindeutig sein soll).

#8

Und was ist der Primärschlüssel der Tabelle?

Der Primärschlüssel ist ein anderes numerisches Feld Namens
‚Nr‘, dessen Inhalt ich vergebe.

Wäre es nicht einfacher, deine Feldkombination als zusammengesetzten Primärschlüssel zu nehmen - na egal, ich will nicht darauf herumreiten…

Dürfen denn auch Nullwerte vorkommen?

Null Nein - Leer, Blanks aber schon.

Willst du auch einzeln nach den Feldern suchen?

Es kann schon vorkommen, dass ich so Abfragen mache wie:
SELECT * FROM tabXXX WHERE UData = ‚aaaa‘;
Wobei mir das nicht so wichtig ist…

Wichtig ist für mich wenn ich ein
SELECT * FROM tabXXX WHERE UData = ‚aaaa‘ AND NodeID = ‚bbbb‘
AND Class = ‚cccc‘;
mache, das es möglichst schnell geht (Vollgas!!!) und das ich
dann nur maximal 1nen Datensatz zurück bekomme oder keinen
(weil die Kombination aus UData, NodeID und Class ja eindeutig
sein soll).

Da sollte dann der UNIQUE INDEX schon helfen.

#9

Da sollte dann der UNIQUE INDEX schon helfen.

Das ist es ja … es funktioniert ja beides: „Unique Index“ oder „Unique Constraint“.
Ich frage mich nur: Wo ist der Unterschied?!?

#10

Ich frage mich nur: Wo ist der Unterschied?!?

Hallo!

Wie du bereits festgestellt hast, macht das RDBMS in beiden Fällen das selbe. Nicht nur SQL Server, sondern auch Oracle, Sybase, etc.

In meinen Augen macht es Sinn, das Statement zu verwenden, das dem angestrebtem Charakter aus Sicht des DB-Designs am besten entspricht, so dass das Script oder DB-Design selbsterklärend ist. Soll ausschließlich ein Constraint sichergestellt werden und ist die Performance egal, dann verwende UNIQUE CONSTRAINT, sonst UNIQUE INDEX.

ciao,
Bernhard

#11

Ja, es ist in der Tat gehüpft wie gesprungen. Siehe auch in der Doku:

SQL Server erstellt automatisch einen eindeutigen Index, um die Anforderung an die Eindeutigkeit für die UNIQUE-Einschränkung zu erzwingen.

#12

Sanx…
Hallo Reinhard,
Danke, dass Du Dich solange mit mir herum geschlagen hast.
…from michL

#13

sanx from michL
…