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

Ответ 1

В общем, есть ли что-то, что я делаю неправильно или могу улучшить?

В целом, я не вижу больших недостатков в вашей текущей настройке или схеме.

Что я задумал, так это ваш раздел на 3 пользовательских * таблиц. Я получаю то, что вы хотите, чтобы ваше намерение было (разные вещи, связанные с пользователем), но я не знаю, пойду ли я с тем же самым делом. Если вы планируете отображать только данные из таблицы User на сайте, это прекрасно, так как другая информация не требуется несколько раз на одной странице, но если пользователям нужно использовать свое настоящее имя и отображать их настоящее имя (например, Джон Доу вместо doe55), чем это замедлит ситуацию, когда данные станут больше, так как вам могут потребоваться объединения. Наличие разделения Preferences похоже на личный выбор. У меня нет аргументов в пользу и против него.

В ваших таблицах "многие-ко-многим" не потребуется дополнительный PK (например, PostFavoriteID). Комбинированного первичного значения как PostID, так и UserID будет достаточно, так как PostFavoriteID никогда больше не используется. Это относится ко всем таблицам соединений

Есть ли какая-либо причина, по которой я не должен комбинировать ExternalAccounts таблицу в таблицу UserProfiles?

Как и в предыдущем. ответ, я не вижу недостатка или недостатка. Я могу разместить оба в одной таблице, так как значения NULL (или, может быть, лучше -1) меня не беспокоят.

Есть ли причина, по которой я не должен комбинировать таблицу PostStats в таблицу Posts?

Я бы поместил их в ту же таблицу, используя триггер для обработки приращения таблицы ViewCount

Должен ли я расширить дизайн, чтобы включить функции, которые мы делаем в вторую версию, чтобы начальная схема может его поддерживать?

Вы используете нормализованную схему, поэтому любые дополнения могут быть выполнены в любое время.

Я могу что-то сделать, чтобы оптимизировать дизайн БД для Solr индексация/производительность/что?

Не могу сказать, еще не сделал этого, но я знаю, что Solr очень мощный и гибкий, поэтому я думаю, что вы должны делать все хорошо.

Должен ли я использовать более естественные первичные ключи, такие как Имя пользователя вместо UserID или код zip/area вместо суррогатное местоположениеID в местах таблица?

Здесь есть много тем, обсуждающих это. Лично мне больше нравится суррогатный ключ (или другой уникальный номер ключа, если он доступен), так как он делает запросы более легкими и быстрыми, поскольку поиск в int упрощается. Если вы разрешаете изменение имени пользователя/электронной почты/всего-своего-ПК, то есть требуются массовые обновления. С помощью суррогатного ключа вам не нужно беспокоиться.

Я также хотел бы добавить такие вещи, как created_at, last_accessed в (лучше всего сделать с помощью триггеров или процедур IMO), чтобы иметь уже имеющуюся статистику. Это может реально дать вам ценную статистику.

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

Ответ 2

Я не понимаю, что происходит с вашими таблицами User * - они настроены так, как будто они 1:1, но диаграмма отображает символ "один ко многим" (символ ворона).

ExternalAccounts и UserSettings могут быть нормализованы далее (в этом случае они тогда будут 1-ко-многим!), что даст вам более удобную конструкцию - вам не нужно будет добавлять дополнительные столбцы в вашей схемы для дополнительных внешних учетных записей или типов уведомлений (хотя это может быть менее масштабируемым с точки зрения производительности).

Например:

ExternalAccounts
    UserId int,
    AccountType varchar(45),  
    AccountIdentifier varchar(45)

позволит вам хранить учетные записи LinkedIn, Google и т.д. в той же структуре. Аналогичным образом, дополнительные типы уведомлений могут быть легко добавлены с использованием такой структуры, как:

UserSettings
    UserId int,  
    NotificationType varchar(45),  
    NotificationFlag ENUM('on','off')

HTH