[Tvartom]

Hej!
Håller på med databasdesign (MySQL) av ett tidssytem.
Ska knyta vissa objekt till specifika dagar.

Eftersom `mydays` bara ska finnas max en post per dag,
ska en date-kolumn ha ett unikt index.
Det fungerar uppenbarligen att ha date som primary,
min fråga är om det finns annan aspekt som gör att
att man ändå inte bör använda det så här?
Jag har nämligen aldrig sett detta någon annanstans.

Med date-kolumn som primary:

CREATE TABLE mydays (
 id DATE NOT NULL,
 mylabel VARCHAR(45) NULL,
 PRIMARY KEY (id)
) ENGINE=InnoDB;

CREATE TABLE mydata (
 id INT NOT NULL AUTO_INCREMENT,
 dateid DATE NOT NULL,
 content VARCHAR(45) NULL,
 PRIMARY KEY (id),
 KEY (dateid),
 FOREIGN KEY (dateid) REFERENCES mydays (id)
) ENGINE=InnoDB;

Alternativet är att lägga ett separat unikt index:

CREATE TABLE mydays2 (
 id INT NOT NULL AUTO_INCREMENT,
 myday DATE NOT NULL,
 mylabel VARCHAR(45) NULL,
 PRIMARY KEY (id),
 UNIQUE KEY (myday)
) ENGINE=InnoDB;

Vad anser ni?
/ Lasse

[Jonas]

Ett ID på en post skall vara något unikt, och enbart användas för att kunna länka ihop olika data.
ID på en post skall inte behöva vara synligt för en användare/brukare.

Jag skulle rekommendera att du använder ett fält till med DATE & UNIQUE på istället. Eftersom du är ute efter något estetiskt.

[Tvartom]

Tack för ditt svar Jonas.

Fördelarna jag ser är att jag kan söka i mydata-tabellen på datumintervall utan att behöva en join.
(Datastrukturen här är en stark förenkling av verkligheten då den även innehåller versionhantering, så jag har redan andra joinar.)

Anledningen till att jag har mydays är att jag kan vara säker på att det inte skapas poster med dagar i mydata som inte är definierade i mydays.

[emilv]

Originally posted by Tvartom@Aug 19 2009, 15:22
Anledningen till att jag har mydays är att jag kan vara säker på att det inte skapas poster med dagar i mydata som inte är definierade i mydays.

Använd foreign keys för det.