Читал на оф. вики вводную часть

Выбирать надо список чатов с кол-вом непрочитанных сообщений. Остальное вроде стандартно - список сообщений чата с фильтрами по дате обновления, с пагинацией, инфа о чате, онфа о прочитанности сообщения

Может, есть более комфортная или быстрая схема работы? Подозреваю, что когда-нибудь захотят скрывать сообщения для себя, не из чата

Чаты групповые

Зачем чат писать в бд ?

Чтобы кудо-то сохранять сообщения)

Ещё варианты?)

В плейн тексте хранить сообщения и индексы самому делать

Чаты групповые

А зачем id в chat_user? Что такое last_read_id, id последнего прочитанного пользователем сообщения в этом чате? А вообще, какой именно чат моделируется? Например, получается, что все сообщения "ничьи"?

Ага, у меня это получится лучше, чем у недалёких разработв бд)

last_read_id - да, id последнего прочитанного пользователем сообщения в этом чате Ну, обычный чат) По поводу "ничьи" - сорян, когда накидывал схему для чата, забыл - в messages есть user_id

Маленький вопрос у меня возник. Где подробно можно почитать про репликацию в постгресе и так же про logical decoder'ы?

Продублирую мой простой вопрос

Я так понимаю, что он очень простой

Добавил user_id и изменил связи в схеме с user_message

last_read_id - да, id последнего прочитанного пользователем сообщения в этом чате Ну, обычный чат) По поводу "ничьи" - сорян, когда накидывал схему для чата, забыл - в messages есть user_id

И как Вы этот last_read_id собираетесь поддерживать? Это ссылка на id в messages (где FK, в таком случае)? А этот id в messages генерируется sequence (который, кстати, не обязан выдавать возрастающие со временем значения в параллельных процессах)?

Я так понимаю, что он очень простой

Про логическую? В основном, в документации....

Про логическую? В основном, в документации....

Да, про нее

А есть смысл читать какие-то книги, где более подробно об этом рассказывается?

И как Вы этот last_read_id собираетесь поддерживать? Это ссылка на id в messages (где FK, в таком случае)? А этот id в messages генерируется sequence (который, кстати, не обязан выдавать возрастающие со временем значения в параллельных процессах)?

Очень просто, буду обновлять у chat_user это поле при прочтении сообщения, эвент о прочтении летит от клиента. FK тоже есть

не нарисовал

Поправил) https://drive.google.com/file/d/1Rouq7WyJeWo5c47U0k-RBaaJ0Eagz9Tr/view?usp=sharing

Очень просто, буду обновлять у chat_user это поле при прочтении сообщения, эвент о прочтении летит от клиента. FK тоже есть

А, понятно. Тем не менее, зачем id в char_user?

А есть смысл читать какие-то книги, где более подробно об этом рассказывается?

А Вы это видели в какой-то книге? Она же в vanilla PostgreSQL только что появилась...

Это единственное место, где можно указать последнее прочитанное сообщение. Там конкретный пользователь в конкретном чате. А клиенту нужно галочку о прочтении ставить

А Вы это видели в какой-то книге? Она же в vanilla PostgreSQL только что появилась...

Не видел. Я кроме доки по постгресу ничего не читал

Это единственное место, где можно указать последнее прочитанное сообщение. Там конкретный пользователь в конкретном чате. А клиенту нужно галочку о прочтении ставить

Ещё раз —- зачем в этой таблице _поле_ id?

На неё же даже ничего не ссылается, какой вообще смысл в суррогатном ключе в таком случае?

Не видел. Я кроме доки по постгресу ничего не читал

Я вот тоже в книгах этого ещё не видел.

Ещё раз —- зачем в этой таблице _поле_ id?

Понял, про что вы) Проще работать. А она накладывает какую-то нагрузку?

Понял, про что вы) Проще работать. А она накладывает какую-то нагрузку?

Не существенную. Просто смысла в нём никакого нет. ;)

Не думаю, что это как-то ускорит/замедлит/увеличит комфорт работы с базой)

Не думаю, что это как-то ускорит/замедлит/увеличит комфорт работы с базой)

<troll> Так почему бы тогда не добавить по парочке случайных полей в каждую из таблиц (с тем же обоснованием)? </troll> ;)

ок, объясню: orm не умеет из коробки работать с композитными ключами у модели, ей нужен один primary ключ. В этом случае это не модель, а таблица связи, но это уже просто сила привычки) Ок, убрали id из таблиц связи

Тут как бы куб получается) 3 сущности друг с другом многие-ко-многим)

Тут как бы куб получается) 3 сущности друг с другом многие-ко-многим)

А (в одном из вариантов) что такое user_messages? Разве (почти) всей этой информации нет в других таблицах?

в postgres нет графов?)

в postgres нет графов?)

А зачем? В реляционках графы моделируются таблицей связей (from_node, to_node).

А (в одном из вариантов) что такое user_messages? Разве (почти) всей этой информации нет в других таблицах?

Есть, но там есть мета-информация о конкретном сообщении пользователя (прочитанность). Возможно, когда-то понядобится у конкретного пользователя удалять сообщение. Тут фигня в том, что легко выбирать то, что нужно, но при добавлении сообщения все пользователям должны добавиться связи на это сообщение, а при присоединении пользователя к чату нужно добавить связи для пользователя на все сообщения чата

Есть, но там есть мета-информация о конкретном сообщении пользователя (прочитанность). Возможно, когда-то понядобится у конкретного пользователя удалять сообщение. Тут фигня в том, что легко выбирать то, что нужно, но при добавлении сообщения все пользователям должны добавиться связи на это сообщение, а при присоединении пользователя к чату нужно добавить связи для пользователя на все сообщения чата

А что Вам нужно выбирать-то? А прочитанность для _каждого_ сообщения —- это просто "мощнее", чем last_read_id в альтернативной схеме... оно Вам точно нужно?

Нет, не нужно, но есть подозрение, что появится функция "Удалить сообщение у себя"

Нет, не нужно, но есть подозрение, что появится функция "Удалить сообщение у себя"

Тогда Вам нужно модель уточнить, IMHO. Т.е. для себя определить, какие Вам нужны возможности, какие у Вас ограничения, и прикинуть запросы... Кстати, почему бы не посмотреть на готовые решения для аналогичных задач? Например, начиная отсюда: https://stackoverflow.com/questions/6541302/thread-messaging-system-database-schema-design

Я смотрел, и всё сводится к этим 2-м вариантам, причем доминирует почему-то вариант с user_message, но я не могу понять, почему

Вариант без нее хорошо уменьшает нагрузку, но усложняет получение списка чатов с кол-вом непрочитанных сообщений

Я смотрел, и всё сводится к этим 2-м вариантам, причем доминирует почему-то вариант с user_message, но я не могу понять, почему

Наверное, у них есть требование хранения "прочитанности" каждым пользователем для каждого сообщения. Если у Вас такого требования нет, то, казалось бы, и такая таблица Вам не нужна.

Не думаю, что такое требование вообще резонно, если честно

Спасибо

Вариант без нее хорошо уменьшает нагрузку, но усложняет получение списка чатов с кол-вом непрочитанных сообщений

А в чём сложность-то? Вот производительность этого запроса может быть не очень, но тут уже простого (без недостатков) решения сходу и не придумаешь, мне кажется...

А в чём сложность-то? Вот производительность этого запроса может быть не очень, но тут уже простого (без недостатков) решения сходу и не придумаешь, мне кажется...

на raw-запросе - ни в чем)

Маленький вопрос у меня возник. Где подробно можно почитать про репликацию в постгресе и так же про logical decoder'ы?

В документации на PG вероятнее лучше всего написано. Книг по PG крайне мало, на русском вообще одна была только. Вряд ли в книгах что то будет по репликации.

ок, объясню: orm не умеет из коробки работать с композитными ключами у модели, ей нужен один primary ключ. В этом случае это не модель, а таблица связи, но это уже просто сила привычки) Ок, убрали id из таблиц связи

Выброси нахрен такой ORM ... Все нормальные умеют.

ок, объясню: orm не умеет из коробки работать с композитными ключами у модели, ей нужен один primary ключ. В этом случае это не модель, а таблица связи, но это уже просто сила привычки) Ок, убрали id из таблиц связи

Мммммм джааанго да?

нет, но популярные фреймворки так и работают - ror/django/laravel, чё там еще забыл)

Все ф топку!

Так можно и на самописные фреймворки с багами вернуться)

нет, но популярные фреймворки так и работают - ror/django/laravel, чё там еще забыл)

Они умеют работать с промежуточными таблицами без одного primary, но у модели должен быть один ключ, иначе обновить или удалить модель трудно (если, конечно, не висит уникальный составной ключ)

Самописные фреймворки могут быть написаны лучше

Нуну, инди-разработчик типа круче тысячных коммьюнити

Могут :)

И у него есть на это время

Но вообще это оффтоп

Да, давай закругляться) лучше по чатам че-нибудь подскажите, вдруг можно проще сделать)

Подскажите, как сделать выгрузку выборки в формате sql , а не csv?

Подскажите, как сделать выгрузку выборки в формате sql , а не csv?

pg_dump

он же таблицы дампит, а мне надо выборку

дамп делает копи. Копи можно и руками сделать.

а если вьюшку сдампить?

воспользуйтесь средствами какого-нибудь гуи

там можно экспортировать данные в виде скриптов уже практически везде

умели бы они еще сразу балк инсерт генерировать...

Подскажите, как сделать выгрузку выборки в формате sql , а не csv?

а вам для каких целей?

для миграции данных в другую субд

через pgadmin 3 не нашел как, там только csv

вариант создания новой таблицы и наполнения им данными из выборки как-то костыльно и некрасиво)

ну Datagrip точно умеет. Кто использует DBeaver, там же тоже есть этот функционал?

Люди, подскажите пожалуйста, почему в бд очень много wait_eventов типа buffer_mapping или buffer_io ? Никто не сталкивался? Что значая данные события понятно.

ну Datagrip точно умеет. Кто использует DBeaver, там же тоже есть этот функционал?

я бы посоветовал navicat. во первых он может коннектиццо к разным DB, во вторых прекрасно реализует экспорт результата запроса в виде sql файла

я бы посоветовал navicat. во первых он может коннектиццо к разным DB, во вторых прекрасно реализует экспорт результата запроса в виде sql файла

Он ощутимо дороже

Люди, подскажите пожалуйста, почему в бд очень много wait_eventов типа buffer_mapping или buffer_io ? Никто не сталкивался? Что значая данные события понятно.

https://postgrespro.ru/docs/postgresql/9.6/monitoring-stats В основном disk io

для миграции данных в другую субд

Тута (али здеся? всё время путаю...) либо искать средства на ресурсах целевой СУБД и прыгать, самоудовлетворяясь и набивая шишки, либо самописные костыли на php, python, perl, java, C/C++, asm...

https://postgrespro.ru/docs/postgresql/9.6/monitoring-stats В основном disk io

спасибо почитаю

Всем привет! Есть проблема с работой pgbouncer. По lifetime pgbouncer рвет соединение с postgres, при этом не рвет соединение с клиентом. Как такие проблемы решать? Проблема в том, что pgbouncer сбрасывает состояние соединения, а клиент об этом даже не знает

Как вообще правильно работать клиенту с pgbouncer?

Привет! Нет соединения с postgre (pgadmin3). В конфах изменений не делал. Как исправить?

ошибка-то какая?

Для того, чтобы принимались любые соединения, нужно слушать не просто 127.0.0.1/32, а 0.0.0.0/32

Для того, чтобы принимались любые соединения, нужно слушать не просто 127.0.0.1/32, а 0.0.0.0/32

добавить?

Можете просто заменить 127.0.0.1/32 на 0.0.0.0/32 и перезагрузить postgresql сервер

Для того, чтобы принимались любые соединения, нужно слушать не просто 127.0.0.1/32, а 0.0.0.0/32

Он слушает * - это даже круче 0.0.0.0... А так да pg_hba поправить надо

0.0.0.0/32 - это што

ошибка-то какая?

нет соединения