Hej!
Innan jag läst kurser om databas-design så gjorde jag alltid tabeller som hade en primärnyckel med exempelvis namnet id. Detta är ju en så kallad surrogat-nyckel och när jag modellerar (Er-modell, Relationsmodell etc) så använder jag mig inte av surrogatnycklar utan istället naturliga nycklar, dvs sådana som har en logisk relation med övriga attribut.
Låt oss säga att jag har följande tabell i två olika versioner.
Version med naturlig-nyckel
Användare (Användarnamn, Lösenord, Förnamn, Efternamn)
Primärnyckel: Användarnamn
Version med surrogat-nyckel
Användare (Id, Användarnamn, Lösenord, Förnamn, Efternamn)
Pirmärnyckel: Id
Nackdelen som jag ser det med naturliga nycklar, är att man ibland kan få använda flera attribut för att bilda en sammansattnyckel. Detta kan ju bli lite bökigt när man använder främmande nycklar osv. Använder man sig av en surrogatnyckel så försvinner ju dessa problem direkt.
Om jag exempelvis har en relation med den naturliga-nyckeln användarnamn så vore väl en korrekt transformering vid implementering vara att sätta ett unique-constraint på användarnamn och sedan lägga in en surrogat-nyckel vid exempelvis namnet Id.
Ska man konskvent alltid använda sig av surrogatnycklar? Hur gör man i verkligheten, i riktiga system?
in general: don't use an auto_increment when there is a perfectly good natural key available (which happens to consist of only one column)
Detta låter ju som en rimlig lösning om det inte vore för att vissa hävdar att en nyckel ska vara av en så liten datatyp som möjligt... Vad är en lämplig definition för en surrogatnyckel om man exempelvis använder sig av int? Det beror väl naturligtvis på hur många unika index man vill kunna hålla?