Är det bra att göra så, eller kan det vara en fördel att göra:
UserProperties
userID [int]
propertyID [int]
Category
id [int]
description [varchar]
Property
id [int]
categoryID [int]
description [varchar]
för att då hämta categoryID via join på propertytabellen.
Jag kommer att ganska ofta ställa frågor som.
"Hämta alla användare som har propertyA i kategori CatA och som har propertyF eller propertyK i kategori CatY"
Hur skall det lämpligen indexeras? Finns det andra - bättre - sätt att lägga upp det på?
Som jag ser det blir det viss redundans i mitt första alternativ, men för att uppnå prestanda i sökningar kanske det är det bästa alternativet?
Tabellen category lär innehålla ungefär 20 poster
Tabellen property lär innehålla ungefär 200 poster
Tabellen userProperty lär innehålla ungefär 3 000 000 poster
Jag skulle ha valt ditt första upplägg vid en första anblick så här - det känns intiutivt bättre. Det går iofs att dela upp tabellen UserProperties i två tabeller, men jag tror väl inte att man tjänar något på det eller om det ens är rätt att göra så. Men, det går :)
Vad gäller indexering, så är det väl bara UserProperties.userID som är nödvändig att indexera, eftersom det är i den tabellen det kommer att bli tungrott (<-- tänk eka ;)). Förvisso kan det väl tänkas att din primärnyckel i den tabellen kommer att bestå av mer än en kolumn om du nu inte har ca 3 miljoner användare och varje användare bara kan ha en kategori och en egenskap. Det tråkiga med att ha kombinerade nycklar är att man tappar prestanda... dock går ju vissa saker inte att undvika, så himla enkelt. (Jag läste just första raden i ditt inlägg... och insåg att jag skriver onödig text.)
Nu känns det som om jag håller på att snöa in på något annat här och det är inte ens vinter än... min röst faller ändå på det första alternativet.
Ett bra beskrivande case. Måste du ha alla poster tillgänglig och var har du TimeStampén?
Då borde du kunna få två fall. Normalt direkt och effektivt och en segare med historik.
Jobba alltid för en levande kärna.
Lasp. Varför skulle TimeStamp vara viktigt i detta fallet? Jag sparar egenskaper som en användare har. Exempelvis:
IT - Gillar webForum
IT - Gillar inte IDG
Mat - Gillar fläskfilé
där har du två kategorier och tre egenskaper.
Jag kommer inte att spara någon som helst historik i någon av tabellerna. Tabellen med tre miljoner poster är uträknad genom att ta ((antal användare*antal egenskaper)/2), då jag kallt räknar med att ingen väljer alla tillgängliga egenskapsval.
Jag kan inte sätta nyckeln enbart på userID eftersom en användare kommer att kunna ha flera egenskaper. Jag kan inte sätta på userID och categori eftersom en användare kan ha flera kategorier. Däremot kan jag sätta nyckeln över userID, categoryID och propertyID. Eftersom en användare endast kan ha samma egenskap en gång.
259 ms totalt · 4 externa anrop · v20260731065814-full.6fe65c25
