Man kan inte säga att man generellt ska undvika syntetiska primärnycklar.
Jag säger tvärtom , undvik naturliga primärnycklar i 9 fall av 10.
Speciellt viktigt då det är flera kolumner, tänk att göra en många-till-många relation, givet att du har t.ex två PK bestående av 4 kolumner så får du du 8 kolumner i kopplingstabellen jämfört med två kolumner om du kör syntetiska primärnycklar.

Det där med anomalier med syntetiska PK förstår jag inte, man är med det 100% säker på att man inte har dubletter. Och självklart har man foreign key constraints och valideringar av data ändå.

En primärnyckel ska vara unik och inte ha en mening, då denna "mening" kan ändras, personnummer är ett exempel.

Vad gäller prestanda så är joins mellan char avsevärt mycket slöare jämfört med integers. Så pass att det kan orsaka upplevd seghet med mycket data. Och vad gör man då, designar om databasen? Njae....

Vi kan kasta in tillverkare/märke som en VARCHAR i produkttabellen också. Blir mindre kul, ur prestandasynpunkt, när kunder ska kunna filtrera produkter efter färger, storlekar, tillverkare, etc. :)

Jag skulle påstå att prestandaoptimering alltid är ett självändamål. Oavsett om det är 1 eller 1 miljon användare vill man ha en rapp databas som inte tar onödigt mycket resurser i anspråk. Skalbarhet är den viktigaste relaterade aspekten, men den blir oväsentlig vid för dålig prestanda då lösningen blir för kostsam för att skala upp.

Nej, när man bygger en databasstruktur där en inbyggd kvalitetskontroll i allmänhet är otroligt viktiga aspekt av datahanteringen är kvalitetskontrollen primär. De allra flesta moderna webbapplikationer faller utanför denna kategorin.

Och om du sedan tittar på uppstickarna som växer snabbast och ligger i framkant i utvecklingen så har de en helt annan uppfattning. De-normalisering, eventual consitency, begränsning av joins, uteslutande av foreign keys osv är deras mantra. Sanningen ligger väl snarare i att varje applikation har olika aspekter som väger olika tungt. Att påstå att man måste följa ACID för att använda en relationsdatabas eller säga att data endast får sparas i 3NF är för mig ungefär lika sant som de som att man ska använda moderna graf-databaser till precis allt.

Din tanke där är lika mycket på utdöende som den är på ingång skulle jag vilja påstå. Det blir allt vanligare med system där andra primärnycklar än ett auto increment används. Men vad som blir ovanligare är system där man försöker hitta en unik identifierare som redan finns i varje rad. Då blir man nämligen tvungen att definiera sin data mycket hårdare än vad man kan i de flesta agila miljöer eller mer än vad man vill i de flesta miljöer med användargenerat innehåll. Dessutom är det som redan påstått rent kasst ur prestandasynpunkt. Den prestandavinst som görs på de flesta primary key lookups är högst väsentlig, både med och utan joins och när det gäller innodb (vi pratar trots allt mysql här) är den även högst relevant för alla användning av sekundär-index.

Ja, jag skulle påstå att det är den enskilt största nyttan med naturliga PK, men för mig är den verkligen sekundär. Det är väldigt sällan man manuellt går igenom databasen för de allra flesta webbapplikationer och om man då måste skriva en join-sats för en kolumn eller två för att kontrollera finner jag inte så intressant.