[Conny Westh]

Ursprungligen postat av martine

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:

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).

[qson]

Jag håller på med en liknande lösning, och precis det du frågar om finns i MySQL, eller åtminstone i MyISAM-motorn.
I din tabell har du två kolumner: AnstalldId och RapportId.
Skapa sedan en PRIMARY KEY bestående av båda dessa kolumner

PRIMARY KEY (AnstalldId, RapportId)

Sedan sätter du RapportId-kolumnen till auto_increment.
Då kommer MySQL/MyISAM att ha egna auto_increment-värden för varje AnstalldId. Du behöver då heller inte lägga in några värden för detta i SQL-frågan, utan sätt RapportId till NULL så fixar MySQL det själv.

Mer info:
http://dev.mysql.com/doc/refman/5.0/...increment.html
(tredje stycket)

[terbon]

Ursprungligen postat av qson

Jag håller på med en liknande lösning, och precis det du frågar om finns i MySQL, eller åtminstone i MyISAM-motorn.
I din tabell har du två kolumner: AnstalldId och RapportId.
Skapa sedan en PRIMARY KEY bestående av båda dessa kolumner

PRIMARY KEY (AnstalldId, RapportId)

Sedan sätter du RapportId-kolumnen till auto_increment.
Då kommer MySQL/MyISAM att ha egna auto_increment-värden för varje AnstalldId. Du behöver då heller inte lägga in några värden för detta i SQL-frågan, utan sätt RapportId till NULL så fixar MySQL det själv.

Mer info:
http://dev.mysql.com/doc/refman/5.0/...increment.html
(tredje stycket)

Tänkte tillägga lite, detta medför då att du inte får 2 primary keys som man kan tro. Utan du får en primary key som är kombination av dessa två. Alltså måste endast dessa tillsammans vara unika. Detta då du endast får ha en primärnyckel per tabell (som du även bör ha om det typ inte är en weak entity tabell eller kopplingstabell som du kan läsa om, om du letar lite om ER diagram).