Как правильно спроектировать БД?

Question

[Леонид]

Пишу учебный проект - сайт знакомств, проектирую БД (postgreSQL).

Есть несколько сущностей:

- чаты;
- стена на странице пользователя;
- фотоальбом пользователя.

Все 3 сущности прекрасно вписываются в следующую архитектуру БД. Есть модели:

- Thread: на него вешаются Post;
- Post: собственно пост;
- User;
- User2Thread - реализует отношение many-to-many между User и Thread. Так же содержит некоторые характеристики, например, права User в этом Thread. Обычно на один Thread создается 2 записи в User2Thread.

Все отлично, я доволен)) НО! Захотелось к некоторым типам Thread (к постам на стене пользователя, постам в фотоальбоме) добавить возможность добавления лайков и комментов.

И комменты и лайки вполне вписываются в ту же архитектуру: их так же можно представить в виде Post, которые прикрепляются к Thread. Соответственно, на каждый такой Post (допустим, добавление фотографии в фотоальбом) будет создаваться 2 записи Thread и 4 User2Thread. Итого 7!!! INSERT'ов на 1 фотографию. В таблицах Thread и User2Thread по 1 индексу.

С одной стороны, мня хочется пойти по этому пути, т.к. я получаю: большой функционал описывается небольшим количеством моделей, небольшим и лаконичным API. Код будет легче поддерживать как на бэкенде, так и на фронтенде.

С другой стороны, это избыточно: комменты и лайки можно описать более простыми моделями. Это снизит объем БД и нагрузку. Но вырастет API и сложность поддержки.

У меня, к сожалению, нет опыта работы с большими и нагруженными БД, поэтому мне сложно оценить, на сколько критичен такой рост и такая нагрузка.

Собственно вопрос:

Чем мне грозит такой рост БД? Допустим, будет 1 млрд. фотографий, на который будет создано 2 млрд. Thread и 4 млрд. User2Thread. Лично я не вижу большой проблемы в этом.

В нагрузке на БД в виде 7 INSERT'ов при загрузке одной фотографии я тоже не вижу проблемы. Это все-таки не такое частое действие. На добавление нового поста в чат-тред (предположительно самое частое действие) будет 1 INSERT.

Как бы поступили Вы? Спасибо!

Answer 1

[sim3x]

Чем мне грозит такой рост БД?

ничем. Вероятность, что у тебя внезапно появятся 10^6 пользователей, которые наплодят 10^12 постов и у тебя еще не будет денег на комманду - ничтожно мала

Comments

[Леонид]

Ничем не грозит, потому что взрослые дяди все перепишут?))

Проект учебный. Не идет речь ни о команде, ни о продакшене, ни о коммерции.

Я понимаю, что правильную архитектуру БД для хайлоада я не построю без глубокого изучения, но и не стоит сейчас такой задачи.

Я наткнулся на конкретную граблю и мне интересно, как поступили бы опытные коллеги.

[sim3x]

Леонид: какая грабля?
Где запрос?
Где косты?
Где тесты?

Answer 2

[Максим]

Предлагаю вам воспользоваться полиморфной связью. Лайки и комментарии вы сможете прицепить к любой из моделей.

Comments

[Леонид]

Спасибо! Полезно