SHARE
TWEET

Untitled

a guest Apr 25th, 2019 85 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. >>1388352
  2.  
  3. > Увы, она вызывает не решаемую проблему, когда нужно проверить существую ли приватная конференция между двумя пользователями
  4.  
  5. Действительно. Тогда получается, надо делать таблицу "диалоги" и к ней "диалоги_пользователя", и тогда в "диалогах_пользователя" мы сможем увидеть все беседы, в которых он участвовал.
  6.  
  7. > А в решении с массивами, это делается легко и просто.
  8.  
  9. Решение с массивами - это денормализованная форма. Его можно преобразовать в эквивалентную форму без массивов, с использованием связей вида многие-ко-многим или один-ко-многим.
  10.  
  11. Я не говорю, что массивы это плохо, но я предложил бы сначала сделать нормализованную форму, а только потом оптимизировать её за счет массивов.  
  12.  
  13. >>Это плохо масштабируется, так как у пользователя могут быть тысячи сообщений. И мы не можем быстренько выбрать часть из них.
  14. > Почему? SELECT ∗ FROM participant JOIN messages ON (message.uuid = ANY(participant.messages)) WHERE participant.uuid = ... AND message.date = NOW() - INTERVAL '1 DAY';
  15.  
  16. А этот запрос использует индексы? Он оптимально выполняется? Не будет перебора лишних данных? По-хорошему это надо измерять микробенчмарком.
  17.  
  18. В общем, мне кажется, надо проектировать базу так:
  19.  
  20. - сформулировать общие требования, что мы хотим хранить
  21. - сформулировать требования, что мы хотим делать с данными (вроде: получить список диалогов, получить последние X сообщений в диалоге итд)
  22. - сделать нормализованнюую схему
  23. - оптимизировать ее для быстрого выполнения нужных нам запросов
  24. - в идеале, еще сделать микробенчмарки и убедиться, что все запросы выполняются очень быстро даже на большом объеме данных
  25.  
  26. Если ты хочешь усложнить себе задачу, то можно еще заложить в архитектуру шардинг. Шардинг это разнесение БД на отдельные не связанные друг с другом части, с расчетом, что их можно будет расположить на разных серверах. "Не связанные" - это значит, что ты не можешь делать джойны с таблицами из разных шардов. В мессенджерах обычно огромные объемы данных, большое число пользователей и без шардинга никак. Часто например, шардят как-то по пользователям: данные одной группы пользователей помещаются в один шард, другой - в другой шард итд. Это будет сложно, но интересно, я думаю.
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top