>>1388212

> В случае шифрования, если мы для каждого пользователя делаем разный шифротекст (шифруем сообщение разными ключами), то придется делать несколько копий.
Это не так, в PGP, при шифровании несколькими ключами делается один общий шифротекст.

>>1388216
>> Можно вместо создания бесконечного количества ссылок создать поле с типом ARRAY и помещать в него все ссылки (UUID) на необходимые данные.
>
>Можно, но это будет денормализация. Допустимо, но лучше сначала спроектировать нормализованную схему, а только потом денормализовать. И что там с внешними ключами?
Нормализованная схема это то что я предлагал с "ссылками", и вы предлагали подобную:

>>1380677
>>Если ты хочешь делать для каждого пользователя свою копию сообщения, то не проще ли просто сделать таблицу "диалог", и таблицу "сообщения", где в сообщении стоит ссылка на диалог и ссылка на получателя, кому оно предназначено? То есть, так:
>> ...
>>Кстати, в больших чатах невыгодно будет делать для каждого свою копию сообщения. Выгоднее делать всего одну копию для всех.
>>- id, объединяющий копии одного сообщения
>Это получается что объединяющее копия одного сообщения это отдельная сущность/таблица? Я не понимаю тогда, это получается тоже самое что и я предложил, только колонки в разных таблицах. Ну и контент сообщения в моём предложении находиться только оригинальном, а не дублируется.

Увы, она вызывает не решаемую проблему, когда нужно проверить существую ли приватная конференция между двумя пользователями, т.к. нужно проверить что существует ли приватная Конференция между двумя пользователями (получателями).  А в решении с массивами, это делается легко и просто. Я писал об этом пост >>1387125 >>1388324

>// Проверить существует ли приватный диалог,
>// не смотря на то что один из пользователей когда-то покинул диалог
>SELECT ∗ FROM Dialog WHERE private = true AND (uuid_of_alice = ANY(participants) [b]AND*[/b] uuid_of_bob = ANY(participants));

>И что там с внешними ключами?
PostgreSQL пока не реализовал возможность иметь массив внешних ключей https://commitfest.postgresql.org/19/1252/


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


Ещё один вопросик, про доктрину который я нечаянно запостил в утонувшний тред: https://pastebin.com/raw/ReJ9xD8b