Visa ett inlägg
Oläst 2010-06-18, 10:40 #6
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Citat:
Ursprungligen postat av martine Visa inlägg
Det känns lite som ett feltänk, du vill ha ett rapport-id men det ska inte vara unikt? Är det inte rapport-numrering du är ute efter egentligen? Du kan ha en primary key på båda kolumnerna (med PRIMARY KEY (rapportid,anställdid)) om du nu vill ha det så men frågan är om det inte är bättre med en riktig id med auto_increment och sedan ett numreringsfält om nu det behövs.

Du kan förstås använda din modell men någon automatiskt auto_increment kan du inte få på det viset (eftersom ditt tabellupplägg känns lite som ett hack ;-)

Detta borde göra det du vill:
INSERT INTO Rapporter (RapportId,AnstalldId,Arbetade_timmar) SELECT MAX(RapportId),INSERT_ID(),5 FROM Rapporter WHERE AnstalldId=INSERT_ID();

Och glöm nu inte att ha ett unikt index om du vill vara säker på att inte få dubletter.
Enligt denna lösning så ska givetvis båda kolumnerna i rapport vara PK då blir det automatiskt indexerade på rätt sätt.

Man måste också tänka på att när man lägger upp den första rapporten för en kund så blir max på rapportid NULL och man måste sätta det till 1. i SQL-server finns en funktion som heter ISNULL() som man kan använda vet inte om det finns en motsvarande i MySQL (kollade och det finns syntax: SELECT ISNULL(field,0) FROM TABLE).

Förslag till Kod:
Kod:
INSERT INTO Rapporter (RapportId,AnstalldId,Arbetade_timmar) 
SELECT ISNULL(MAX(RapportId),1),INSERT_ID(),5
FROM Rapporter 
WHERE AnstalldId=INSERT_ID();
Trådskaparen vill använda en nturlig primärnyckel i rapporttabellen för attfå bättre kontroll på informationen och det är bra, det skulle vara omöjligt med autoinkrement i rapport.tabellen.

Mna kan gå ytterligare ett steg och använda en naturlig PK även i kundtabellen med personnr eller orgnr så får du bättre datakvalitet även där (risken för dubletter minimeras).

Att slentrianmässigt använda autoinkrement skapar en databas där man har noll koll på dubbletter. Följaktligen komme rmånga dubbletetr att uppstå med tiden= sämre datakvalitet.

Ett generellt råd är att undvika autoinkrement så långt det är möjligt, använd istället naturliga primärnycklar i så stor utsträckning som möjligt, kombinera kolumner upp till ca 5-6 kolumner till PK vid behov. Först när det blir fler kolumner i PK ska man överväga att gå över till synttiska PK (autoinkrement är en form av syntetisk PK).

Senast redigerad av Conny Westh den 2010-06-18 klockan 10:50
Conny Westh är inte uppkopplad   Svara med citatSvara med citat