Sammantaget ser jag inga stora brister i din nuvarande installation eller schema.
Det jag undrar över är din uppdelning i 3 User*-tabeller. Jag förstår vad du vill att din avsikt var (att ha olika användarrelaterade saker separata) men jag vet inte om jag skulle gå med exakt samma sak. Om du planerar att endast visa data från User tabell på webbplatsen, det är bra, eftersom den andra informationen inte behövs flera gånger på samma sida, men om användarna behöver använda sitt riktiga namn och visa sitt riktiga namn (som John Doe istället för doe55) kommer det att sakta ner saker och ting när data blir större sedan du kan kräver sammanfogningar. Att ha Preferences separat verkar vara ett personligt val. Jag har inga argument för eller emot det.
Dina många-till-många-tabeller skulle inte behöva en extra PK (t.ex. PostFavoriteID ). En kombinerad primär av båda PostID och UserID skulle räcka eftersom PostFavoriteID används aldrig någon annanstans. Detta gäller för alla anslutningstabeller
Som med föregående. svar, jag ser ingen fördel eller nackdel. Jag får lägg båda i samma tabell sedan NULL (eller kanske bättre -1 ) värden skulle inte störa mig.
Jag skulle lägga dem i samma tabell med en trigger för att hantera ökningen av ViewCount bord
Du använder ett normaliserat schema så alla tillägg kan göras när som helst.
Kan inte säga det, har inte gjort det än men jag vet att Solr är väldigt kraftfull och flexibel så jag tycker att du borde klara dig bra.
Det finns många trådar här på SÅ diskuterar detta. Personligen gillar jag en surrogatnyckel bättre (eller en annan unik nummernyckel om tillgänglig) eftersom det gör frågor enklare och snabbare eftersom en int är lättare att slå upp. Om du tillåter en ändring av användarnamn/e-post/vad-din-PK-är än krävs det massiva uppdateringar. Med surrogatnyckeln behöver du inte bry dig.
Vad jag också skulle göra är att lägga till saker som created_at , last_accessed på (bäst att göra via triggers eller procedurer IMO) för att ha viss statistik redan tillgänglig. Detta kan verkligen ge dig värdefull statistik
Ytterligare strategier för att öka prestandan skulle vara saker som memcache, counter cache, partitionerade tabeller,... Sådana saker kan diskuteras när du verkligen överskrids av användare eftersom det kan finnas saker/teknologier/tekniker/... som är mycket specifika. till ditt problem.