nicht angemeldet
Hallo Michael,
das ist einer der Gründe, weshalb ich so gegen AutoInkrement-Werte wettere: Sie machen die intuitive Mengen-Eigenschaft von Tabellen kaputt.
Für mich gibt es im Datenbankdesign grundsätzlich zwei verschiedene Arten von Tabellen. Die einen mit wirklichem Inhalt, und da möchte ich jeden Datensatz so einfach wie möglich referenzieren können. Und das ist IMHO nun mal am Besten mit einem unique integer als Primärschlüssel zu bewerkstelligen.
Und dann gibt es Tabellen, welche im Wesentlichen nur Verknüpfungsinformationien enthalten (m:n-Beziehungstabellen). Hier gibt es nicht zwangsläufig einen Primärschlüssel, und wenn dann meist einer, der alle notwendigen Felder, welche Foreinkeys auf die verknüpften Tabellen sind, beinhaltet. (Was für eine Satzkonstruktion *tststs*)
Klar könnten sich oft auch in den 'Inhaltstabellen' andere Primärschlüssel definieren lassen. Aber die Datensatzreferenzierung wird dadurch meist erheblich komplizierter.
Und da sind wir dann bei der Generierung eines eindeutigen Primärschlüssels. IMHO muß das eine atomare Funktion sein, da sonst bei Mehrprozeßanwendungen (und welche Anwenungen sind das heute nicht) kein zuverlässiger Primärschlüssel generiert werden kann.
Mir persönlcih gefällt die mySQL-Lösung auch nicht. (Wobei ich anmerken will, daß mir vieles bei mySQL fehlt)
Ich arbeite lieber mit Mechanismen wie Trigger und Generatoren, wenn es die Datenbank nur zuläßt. Damit wäre übrigens Dein Beispiel recht elegant zu lösen, auch wenn ein automatisch inkrementiertes Feld im Spiel ist.
CREATE TEMPORARY TABLE X AS
SELECT * FROM <tabellenname>
WHERE <bedingung>;
»»
UPDATE X
SET <feldname> = <wert>;
»»
INSERT INTO <tabellenname>
SELECT * FROM X;
Wenn ich mit Mengen arbeiten darf, dann sind solche Operationen ganz prima möglich. Habe ich aber auch nur eine einzige AutoInkrement-Spalte, dann kann ich so etwas vergessen.
Nur solltest Du Workaroundlösungen, die durch Applikationsmängel notwendig werden, nicht zur Be/Abwertung eines bestimmten Konzepts heranziehen. Andere Datenbanken bieten durchaus Lösungen für die Realisierung beider Ansätze. (Habe ich schon gesagt, daß mir bei mySQL vieles fehlt?)
Und ich muß dann im Quelltext meiner Anwendung auch tatsächlich die komplette Liste der Spaltennamen einbrennen (und diese bei jeder Änderung des Tabellenformats mit anpassen), die mich an dieser Stelle doch gar nicht interessieren sollte ...
Irgendwann muß Du doch auch konkret werden. IMHO ist es egal, ob eine Anwendung nur weiß, in welcher Reihenfolge welche Feldinhalte in einem INSERT-Statment vorkommen müssen, oder auch deren Namen. Und 'select * form Tabelle' kann auch durchaus derart unperformant sein, daß man es besser bleiben läßt.
(der "seinen" Operateuren einen Benutzerkennung-Kloner mit CGI-GUI geschrieben hat, damit diese die Probleme von Kunden reproduzieren können, ohne sich mit deren Benutzerkennung und Passwort anmelden zu müssen - denn erstens kennen die Operateure das nur verschlüsselt gespeicherte Passwort des Kunden nicht und zweitens ist mehrfaches paralleles Login verboten - aber leider keinen Einfluß auf die Tabellenformate des verwendeten Fremdprodukts hatte und sich über die AutoInkrement-Spalte aus den beschriebenen Gründen mächtig geärgert hat)
Womit wir wieder beim RL wären, in dem sowieso jegliche sinnvolle theoretische Überlegung durch die mangelhafte Implementierung (anderer *g*) zunichte gemacht wird :-(
Grüße
Klaus