*Markus: MYSQL / Zwei Zähler in einer Tabelle?

Guten Abend,

ich habe folgende MySQL-Anweisungen:

CREATE TABLE Eintrag

(e_id                  INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,

t_id                  INTEGER NULL,

verfassername         VARCHAR(60) NULL,

erstellungsdatum      DATE NULL,

titel                 VARCHAR(80) NULL,

text                  VARCHAR(4000) NULL

);

CREATE UNIQUE INDEX XPKEintrag

ON Eintrag

(

e_id                  ASC

);

CREATE TABLE Themengebiet

(t_id                  INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,

t_beschreibung        VARCHAR(150) NULL,

t_version             INTEGER NOT NULL AUTO_INCREMENT

);

CREATE UNIQUE INDEX XPKThemengebiet

ON Themengebiet

(

t_id                  ASC

);

ALTER TABLE Eintrag

ADD CONSTRAINT R_0 FOREIGN KEY  (t_id)

REFERENCES Themengebiet

ON DELETE SET NULL

;

Das Problem ist das Attribut t_version. t_version muss ein Zähler sein. MySQL erlaubt aber nichtg mehr als einen Zähler in einer Tabelle, und auch nur dann, wenn es ein Primary Key ist:
"ERROR 1075 (42000) at line 18: Incorrect table definition; there can be only one auto column and it must be defined as a key"
Ein normales Feld als PK zu definieren, nur weil MySQL so konzipiert ist, kommt nicht in Frage.
Welche Möglichkeiten habe ich?

Markus

--
  1. Moin!

    CREATE TABLE Themengebiet
          (t_id                  INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
           t_beschreibung        VARCHAR(150) NULL,
           t_version             INTEGER NOT NULL AUTO_INCREMENT
    );

    Das Problem ist das Attribut t_version. t_version muss ein Zähler sein. MySQL erlaubt aber nichtg mehr als einen Zähler in einer Tabelle

    Wie stellst du dir denn das Ergebnis vor?

    Wenn es funktionieren würde, und in eine leere Tabelle würde das erste INSERT geschrieben:

    INSERT INTO Themengebiet (t_beschreibung) VALUES ('Erstes Themengebiet');

    dann wäre das Ergebnis so, dass t_id automatisch auf 1 gesetzt wird, und t_version ebenfalls.

    Das zweite Insert ergäbe dann für beide Zahlen eine 2.

    Alternativ könnte man natürlich auch drüber nachdenken, dass als Quelle für beide Werte nur ein einziger Counter benutzt wird, dementsprechend wäre t_id immer ungerade, und t_version immer um eins größer und grade.

    In allen Fällen aber würde t_version zwingend mit t_id korrelieren, d.h. du produzierst sinnlose Redundanz, weil sich der Wert von t_version direkt aus dem Wert von t_id errechnen läßt.

    Also: Was planst du genau? Mutmaßlich musst du diese eine Tabelle nochmal in zwei Tabellen aufteilen, dann kriegst du die Möglichkeit eines unabhängigen, weiteren auto_increment.

    PS: auto_increment-Spalten sind automatisch UNIQUE, es bedarf da IMO keines weiteren Indexes. Der zieht nur unnötig Performance.

    - Sven Rautenberg

    --
    "Love your nation - respect the others."
    1. Hallo Sven,

      du hast natürlich recht. Da dachte ich gestern wohl in die falsche Richtung. Das Feld "version" sollte für ein Optimistic Locking vorgesehen sein, aber auf diese Weise würde es ad absurdum geführt werden.

      Markus

      --
  2. Hello,

    zusätzlich zur Antwort von Sven noch eine Anmerkung: falls du mit der Spalte version die "Version" des Datensatzes nachhalten willst, dann solltest du hierfür ggf. einen Trigger verwenden, der entweder beim Update (AFTER UPDATE) oder vor dem Einfügen eines neuen, irgendwie zugehörigen Satzes, (BEFORE INSERT) den entsprechenden Wert bereitstellt.

    MfG
    Rouven

    --
    -------------------
    sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
    "I wish it need not have happened in my time" - "So do I, and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us."  --  J.R.R. Tolkien: "The Lord Of The Rings: The Fellowship Of The Ring"