Nel complesso, non vedo grossi difetti nella configurazione o nello schema attuale.
Quello che mi chiedo è la tua divisione in 3 tabelle User*. Ho capito cosa vuoi che fosse la tua intenzione (avere diverse cose relative all'utente separate) ma non so se andrei con la stessa identica cosa. Se prevedi di visualizzare solo i dati dell'User tabella sul sito, va bene, dal momento che le altre informazioni non sono necessarie più volte sulla stessa pagina, ma se gli utenti devono usare il loro vero nome e visualizzare il loro vero nome (come John Doe invece di doe55), questo rallenterà le cose quando i dati diventano più grandi poiché puoi richiedono join. Avere le Preferences separato sembra una scelta personale. Non ho argomenti a favore né contro di essa.
Le tue tabelle molti-a-molti non avrebbero bisogno di un PK aggiuntivo (ad es. PostFavoriteID ). Un primario combinato di entrambi PostID e UserID sarebbe sufficiente poiché PostFavoriteID non viene mai utilizzato da nessun'altra parte. Questo vale per tutte le tabelle di join
Come con il prec. risposta, non vedo un vantaggio o uno svantaggio. Io potrei metti entrambi nella stessa tabella poiché NULL (o forse meglio -1 ) i valori non mi darebbero fastidio.
Li metterei nella stessa tabella usando un trigger per gestire l'incremento di ViewCount tabella
Stai usando uno schema normalizzato in modo che qualsiasi aggiunta possa essere eseguita in qualsiasi momento.
Non posso dirtelo, non l'ho ancora fatto, ma so che Solr è molto potente e flessibile, quindi penso che dovresti andare bene.
Ce ne sono molti discussioni qui su SO che discutono di questo. Personalmente, mi piace di più una chiave surrogata (o un'altra chiave numerica univoca se disponibile) poiché rende le query più facili e veloci poiché un int viene cercato più facilmente. Se consenti una modifica di nome utente/e-mail/qualunque sia il tuo PK, sono richiesti enormi aggiornamenti. Con la chiave surrogata, non devi preoccuparti.
Quello che farei anche io è aggiungere cose come created_at , last_accessed at (meglio farlo tramite trigger o procedure IMO) per avere alcune statistiche già disponibili. Questo può davvero darti statistiche preziose
Ulteriori strategie per aumentare le prestazioni sarebbero cose come memcache, counter cache, tabelle partizionate,... Tali cose possono essere discusse quando si è davvero invasi dagli utenti perché potrebbero esserci cose/tecnologie/tecniche/... che sono molto specifiche al tuo problema.
