No geral, não vejo grandes falhas em sua configuração ou esquema atual.

O que eu estou querendo saber é a sua divisão em 3 tabelas User*. Eu entendo o que você quer que sua intenção era (ter diferentes coisas relacionadas ao usuário separadas), mas não sei se eu faria exatamente a mesma coisa. Se você planeja exibir apenas dados do User tabela no site, isso é bom, já que as outras informações não são necessárias várias vezes na mesma página, mas se os usuários precisarem usar seu nome real e exibir seu nome real (como John Doe em vez de doe55), isso tornará as coisas mais lentas quando os dados ficam maiores, pois você pode requerem junções. Tendo as Preferences separado parece uma escolha pessoal. Não tenho argumentos a favor nem contra.

Suas tabelas muitos para muitos não precisariam de um PK adicional (por exemplo, PostFavoriteID ). Um primário combinado de ambos PostID e UserID seria suficiente, pois PostFavoriteID nunca é usado em nenhum outro lugar. Isso vale para todas as tabelas de junção

Assim como o anterior. resposta, não vejo vantagem ou desvantagem. Eu posso coloque ambos na mesma tabela desde o NULL (ou talvez melhor -1 ) valores não me incomodariam.

Eu os colocaria na mesma tabela usando um gatilho para lidar com o incremento do ViewCount tabela

Você está usando um esquema normalizado para que quaisquer adições possam ser feitas a qualquer momento.

Não posso te dizer, ainda não fiz isso, mas sei que o Solr é muito poderoso e flexível, então acho que você deve estar indo bem.

Existem muitos tópicos aqui no SO discutindo isso. Pessoalmente, gosto mais de uma chave substituta (ou outra chave numérica exclusiva, se disponível), pois torna as consultas mais fáceis e rápidas, pois um int é pesquisado com mais facilidade. Se você permitir uma mudança de nome de usuário/e-mail/qualquer que seja o seu PK, haverá atualizações massivas necessárias. Com a chave substituta, você não precisa se preocupar.

O que eu também faria é adicionar coisas como created_at , last_accessed at (melhor feito por meio de gatilhos ou procedimentos IMO) para ter algumas estatísticas já disponíveis. Isso pode realmente fornecer estatísticas valiosas

Outras estratégias para aumentar o desempenho seriam coisas como memcache, cache de contador, tabelas particionadas,... Essas coisas podem ser discutidas quando você é realmente invadido por usuários, porque pode haver coisas/tecnologias/técnicas/... que são muito específicas ao seu problema.