Eigentlich gehört das wohl nicht hier her, den Thread relevanten Teil hat sx2008 mit seinen Hinweisen zu den reservierten Wörtern geliefert.
Trotzdem mein Senf zum Thema Index & Co. Auch wenn es mehr oder weniger bekannt sein dürfte, vielleicht hilft es jemand weiter, für absurd halte ich es jedenfalls nicht.
Constraints
===========
Constraint, eine Regel in einem RDBMS, die verschiedene Ausprägungen haben kann und sich z.B. auf einen einzelnen Spaltenwert oder alle Werte einer Spalte oder mehrere Spalten beziehen kann.
Primary Key Constraint, eine spezielle Constraint Form, die bezüglich ein oder mehrerer Spalten Eindeutigkeit und „nicht undefiniert“ fordert. Die Erzeugung der Werte erfolgt häufig über AutoInc Datentypen, Trigger oder Trigger & Generatoren/Sequenzen datenbankseitig, clientseitig dagegen mittlerweile häufig über
GUID oder UUID.
Eine Spalte mit Primary Key Constraint wird häufig als Primärschlüssel übersetzt. Es kann auch Sekundärschlüssel geben, also weitere Spalten, die ebenfalls einen eindeutigen Zugriff erlauben.
Unique Constraint, wie Primary Key, „undefiniert“ jedoch erlaubt.
Foreign Key Constraint definiert die Existenz identischer Feldwerte in einer anderen Spalte (einer anderen Tabelle).
Es gibt weitere Constraint Formen.
Ein Datenmodell kann angelegt werden, ohne einen dieser Constraints zu verwenden. Damit lässt man allerdings wesentliche Merkmale eines RDBMS ungenutzt, was Folgen hat für Exaktheit bzw. Konsistenz und Robustheit der Datenverarbeitung. Sind diese und andere Constraints definiert, so garantiert(!) ein echtes RDBMS die Einhaltung u.a. dieser Constraint Regeln (siehe ACID).
Ich habe bereits Software gesehen, die auf derartigen Datenmodellen ohne Constraints aufsetzt. Der Sinn erschließt sich mir nicht, in Betracht kommen Ahnungslosigkeit, Schlamperei, Faulheit oder der Versuch von Obfuscation.
Indizes
=======
Indizes haben mit Constraints nichts zu tun, sie beschleunigen idealer Weise nur den Datenzugriff. Damit helfen sie allerdings dem RDBMS, die definierten Constraints möglichst leicht (also schnell) einzuhalten.
Der Index ist eine zusätzliche, physikalisch vorhandene Sortierung der Feldinhalte ein oder mehrerer Spalten, ein Index kann dabei ebenfalls die Eigenschaft „unique“ beinhalten. Die Sortierungsmöglichkeiten bzw. der Indexaufbau kann je nach RDBMS verschiedene Möglichkeiten bieten, bspw. als Bitmap Index oder Function Based Index. Außerdem können Indizes auch mehrfach auf identischen Spalten angelegt werden. Falls das nicht versehentlich geschieht: es wird absichtlich evtl. zur Indexreorganisation verwendet, ansonsten verlangsamt es lediglich Einfügen und Ändern von Daten weiter, wie jeder Index.
Indizes haben gar nichts mit Funktionsweise und Logik des Datenmodells zu tun und können gelöscht werden, ohne der Funktion eines Datenmodells (ACID) zu schaden. Es wird lediglich langsamer.
(Ich schließe hier mal extra nicht aus, dass es herstellerabhängige Sonderformen gibt, wo das Löschen eines Index auch die Funktion beeinträchtigt.)
Indizes haben eigene Namen, die allerdings häufig vom
DB System vergeben werden, z.B. im Falle einer Spalte, die mit Primary Key Constraint definiert wurde, ohne die Indexoptionen explizit anzugeben.
Umgang mit Indizes im Client
============================
Da sie nichts zum Datenmodell an sich beitragen, können sie z.B. auch in separaten Skripten verwaltet werden. Wegen Ihrer Unbeständigkeit, ist es auch nicht zu empfehlen, clientseitig Indizes namentlich anzusprechen (außer das Programm dient der Indexverwaltung bzw. erzeugt oder ändert seine eigene
DB „on the fly“).
Ebenso ist es nicht empfehlenswert, Existenz und Art des Index in Spaltenbenennung einzubeziehen. Das gilt auch für alle anderen physikalischen Optionen einer Datenbank. Dieser Teil hat erhebliche Bedeutung bei der so angesagten datenbankunabhängigen Programmierung.
SQL Syntax für Indexdefinition ist kaum standardisiert, Datenmodelle mit eingestreuten Index Statements sind also schwerer zu migrieren.