Като цяло не виждам големи недостатъци в текущата ви настройка или схема.
Това, което се чудя, е вашето разделяне на 3 потребителски* таблици. Разбрах какво искате да имате намерението ви (да имате отделни различни неща, свързани с потребителя), но не знам дали бих тръгнал със същото нещо. Ако планирате да показвате само данни от User таблица на сайта, това е добре, тъй като другата информация не е необходима няколко пъти на една и съща страница, но ако потребителите трябва да използват истинското си име и да покажат истинското си име (като John Doe вместо doe55), това ще забави нещата когато данните станат по-големи, тъй като вие можете изискват съединения. Наличието на Preferences отделно изглежда като личен избор. Нямам аргументи нито за, нито против.
Вашите таблици много към много няма да се нуждаят от допълнителен PK (напр. PostFavoriteID ). Комбиниран първичен от двата PostID и UserID би било достатъчно, тъй като PostFavoriteID никога не се използва никъде другаде. Това важи за всички таблици за свързване
Както и предишната. отговор, не виждам предимство или недостатък. мога поставете и двете в една и съща таблица, тъй като NULL (или може би по-добре -1 ) стойностите няма да ме притесняват.
Бих ги поставил в една и съща таблица с помощта на тригер за обработка на увеличението на ViewCount таблица
Вие използвате нормализирана схема, така че всякакви допълнения могат да бъдат направени по всяко време.
Не мога да ви кажа, все още не съм го правил, но знам, че Solr е много мощен и гъвкав, така че мисля, че трябва да се справяте добре.
Има много теми тук на SO обсъждат това. Лично аз харесвам по-добре сурогатен ключ (или друг уникален цифров ключ, ако е наличен), тъй като прави заявките по-лесни и по-бързи, тъй като int се търси по-лесно. Ако разрешите промяна на потребителско име/имейл/каквото и да е вашият PK, тогава са необходими масивни актуализации. Със заместващия ключ не е нужно да се притеснявате.
Това, което също бих направил, е да добавя неща като created_at , last_accessed at (най-добре чрез тригери или процедури IMO), за да имате вече налични статистически данни. Това наистина може да ви даде ценни статистически данни
Допълнителни стратегии за повишаване на производителността биха били неща като memcache, counter cache, разделени таблици,... Такива неща могат да се обсъждат, когато наистина сте превзети от потребителите, защото може да има неща/технологии/техники/..., които са много специфични на вашия проблем.
