>>1388352

> Увы, она вызывает не решаемую проблему, когда нужно проверить существую ли приватная конференция между двумя пользователями

Действительно. Тогда получается, надо делать таблицу "диалоги" и к ней "диалоги_пользователя", и тогда в "диалогах_пользователя" мы сможем увидеть все беседы, в которых он участвовал.

> А в решении с массивами, это делается легко и просто.

Решение с массивами - это денормализованная форма. Его можно преобразовать в эквивалентную форму без массивов, с использованием связей вида многие-ко-многим или один-ко-многим.

Я не говорю, что массивы это плохо, но я предложил бы сначала сделать нормализованную форму, а только потом оптимизировать её за счет массивов.

>>Это плохо масштабируется, так как у пользователя могут быть тысячи сообщений. И мы не можем быстренько выбрать часть из них.
> Почему? SELECT ∗ FROM participant JOIN messages ON (message.uuid = ANY(participant.messages)) WHERE participant.uuid = ... AND message.date = NOW() - INTERVAL '1 DAY';

А этот запрос использует индексы? Он оптимально выполняется? Не будет перебора лишних данных? По-хорошему это надо измерять микробенчмарком.

В общем, мне кажется, надо проектировать базу так:

- сформулировать общие требования, что мы хотим хранить
- сформулировать требования, что мы хотим делать с данными (вроде: получить список диалогов, получить последние X сообщений в диалоге итд)
- сделать нормализованнюую схему
- оптимизировать ее для быстрого выполнения нужных нам запросов
- в идеале, еще сделать микробенчмарки и убедиться, что все запросы выполняются очень быстро даже на большом объеме данных

Если ты хочешь усложнить себе задачу, то можно еще заложить в архитектуру шардинг. Шардинг это разнесение БД на отдельные не связанные друг с другом части, с расчетом, что их можно будет расположить на разных серверах. "Не связанные" - это значит, что ты не можешь делать джойны с таблицами из разных шардов. В мессенджерах обычно огромные объемы данных, большое число пользователей и без шардинга никак. Часто например, шардят как-то по пользователям: данные одной группы пользователей помещаются в один шард, другой - в другой шард итд. Это будет сложно, но интересно, я думаю.