Доброе утро народ! Делаю чат и такая задача. Я добавил

в таблицу messages.is_view (boolean) Если кто-то его читает он станет правдой.
Проблема в том
1)когда я считаю количество, запрос очень долгое
2)Я каждый раз когда админ открывает чат обновляю вес сообщения от клиента

Вопрос: Есть другой вариант? Вы как реализовали бы?

1) индекс на колонке стоит? 2) усложнить логику, проверяя кто читает чат.

А, я даже не думал про индексирования.🤦‍♂️ 2) чат читает только связанный оператор к сессия и клиенту

Подумай

Допустим есть 2 таблицы - одна хранит инфу для чата, а вторая - для сообщений. Если нужен счётчик, то при добавлении сообщения сохранять количество в таблице с чатом, то есть при выводе не пересчитывать каждый раз, а брать значение из поля. При открытии чата ставить джобу, которая в фоне сделает пересчёт. Ну и также две колонки должно быть для каждой стороны в случае, если участников двое. Это костыль, конечно, но он рабочий. А вообще, то что запрос долго выполняется значит, что он не попал в индексы.

В начале не было заметно. А когда все сообщения перевесил больше 50 лям у меня перевесил по временим больше 20 сек. И куча жалоб

Берёшь чистый SQL, добавляешь перед ним слово explain и выполняешь. В ответе будет инфа есть ли индексы. Если есть, то какие сумел использовать. Или их нет. Если индексов нет, то их либо не существует, либо запрос в них не попал.

Протестировал на таблице с 10 миллионами сообщений: https://pastebin.com/qUem3Dkh ------- --------------- ----------------------- # with index without index ------- --------------- ----------------------- min 712.827 ms 2105.372 ms max 776.636 ms 2137.057 ms avg 735.734 ms 2123.208 ms total 2218.423 ms 6379.078 ms ------- --------------- ----------------------- Order - 1 - - 2 - ------- --------------- -----------------------

Теперь добавьте json column, а там будете искать там где у жсон message.client.chat_id=$model->chat_id

Ни postgres, ни mysql не создают индексы на JSON поля, поэтому они всегда парсятся "как текст", грубо говоря. В JSON полях можно держать только ту информацию, которая никогда и ни при каких обстоятельствах не будет принимать участие в фильтрации.

Хотя спасибо, у меня таблица с самого начала не правильно было продумано

Но можно хитро как-то, если не ошибаюсь, проиндексировать значение какого-то ключика в джсоне в мускле

Это дикие костыли. Лучше всё же изменить структуру таблицы сообщений

это костыль, json туда добавили, чтобы был. Для работы с json есть Монга и прочее

Монга вообще непонятно для чего есть

могу ошибаться, но монга изначально планировался как БД в том числе и для JSON данны. Тогда как в классические SQL базы JSON добавил только в конце 10ых, на фоне роста его популярности в вебе

Та просто объективно хранить данные в формате json это ненужная вещь чаще всего, которую можно ( обычно ) переделать на норм структуру, но лень. Обычно это какие-то метаданные которые можно хранить просто в тексте, а на клиенте вертеть их, кто как хочет. Сейчас же это тип, со своими возможностями, валидацией и тд и тп. Но я думаю, что не один архитектор реляционной БД не будет советовать вообще использовать поле json в базе

» переделать на норм структуру, но лень в итоге выходит прилично параметров , какой нить Яндекс Маркет пришлет JSON с кучей вложенностей , из которых для склада сейчас нужно 10 параметров, а когда что то отвалится - надо знать что пришло. Хранить JSON - как text / longtext внутри БД - большим куском, тоже извратом попахивает.

The space required to store a JSON document is roughly the same as for LONGBLOB or LONGTEXT;

В postgres можно создать индекс на json поле :) CREATE INDEX ON product((info->>'name'));

В мускуле тоже через костыль. Но я не знаю использует ли постгрес физическую линковку или виртуальную.