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!
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?!?
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…
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?!?
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).
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).
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.