Дизайн базы данных социальных веб-приложений: как можно ли улучшить эту схему?

Предпосылки

Я разрабатываю социальное веб-приложение для поэтов и писателей, позволяющее им делиться своими стихами, собирать отзывы и общаться с другими поэтами. У меня очень мало формального обучения проектированию баз данных, но я читал книги, SO и онлайн-ресурсы по проектированию БД, пытаясь обеспечить производительность и масштабируемость без чрезмерного проектирования.

База данных - это MySQL, а приложение написано на PHP. Я' Я еще не уверен, будем ли мы использовать ORM-библиотеку или писать SQL-запросы с нуля в приложении. Помимо веб-приложения, поисковый сервер Solr и, возможно, какой-нибудь клиент обмена сообщениями будут взаимодействовать с базой данных.

Текущие потребности

Схема, которую я собрал ниже, представляет основные компоненты первой версии веб-сайта. Первоначально пользователи могут зарегистрироваться на сайте и выполнять любое из следующих действий:

• Создавать и изменять данные профиля и настройки учетной записи
• Публиковать, отмечать и классифицировать свои записи
• Читать, комментировать и добавлять в избранное других пользователей posts
• "Подписаться" другие пользователи, чтобы получать уведомления о своей активности
• Искать и просматривать контент и получать предлагаемые сообщения / пользователей (хотя мы будем использовать поисковый сервер Solr для индексации данных БД и выполнения запросов такого типа)

Схема

Здесь это то, что я придумал в MySQL Workbench для исходного сайта. Я все еще немного не уверен в некоторых вещах, связанных с реляционными базами данных, так что не торопитесь.

Вопросы

1. В общем, что я делаю неправильно или могу улучшить?
2. Есть ли причина, по которой мне не следует объединять таблицу ExternalAccounts в таблицу UserProfiles?
3. Есть ли какие-нибудь причина, почему я не должен • объединить таблицу PostStats с таблицей Posts?
4. Следует ли мне расширить дизайн, включив в него функции, которые мы делаем во второй версии, просто чтобы убедиться, что исходная схема может поддерживать это?
5. Могу ли я что-нибудь сделать с оптимизировать дизайн БД для индексации Solr / производительности / чего угодно?
6. Следует ли мне использовать более естественные первичные ключи, такие как имя пользователя вместо идентификатора пользователя или почтовый индекс / код региона вместо суррогатного идентификатора местоположения в таблице местоположений?

Спасибо за Помощь!