VeRTak
31.03.2016 - 18:19
Всем привет, имеется мини чат.
1) - Выводим сообщения
2) - Если пользователь пишет сообщение, естественно добавляем его
Нужно хранить только 225 записей, Не могу додумать как реализовать, я думаю тут какой то надо не простой sql запрос наверное или же какие то другие пути? Я вообще думал после добавления сообщения, смотреть сколько вообще есть записей в бд и удалять ненужные, и того получается 3 запроса, или так и должно быть?
В таком случае какой тип лучше дать таблице?
icedfox
31.03.2016 - 20:58
Подумай в сторону разделения:
1. пока чат активен все записи пишутся в tmp табличку.
2. как только чат закончен, записи из tmp переносятся в архив.
Вот во время переноса уже можешь проводить все нужные манипуляции , т.к. это будет фактически разовая операция по сравнению с отправкой данных из активного чата.
VeRTak
31.03.2016 - 21:05
icedfox
Так он активен всегда. Или я что то не так понял под словом активен?
Мне вот что нужно при добавлении 256 сообщения в чат что бы 1-го не было в бд.
Может я зря переживаю, просто чат самое активное место, при 5-6к уников в сутки, не мало сообщений попадаем в чат, там стоит лимит на 255 записей ну 15 записей на страницу. Бывает такая ситуация что нужно у определенно id юзера поменять кое что во всем чате. Если будет 225 записей то проблем не будет, а если миллионы записей, ничего не захлебнется там?
sergeiss
31.03.2016 - 21:12
225 или 255 записей? Ты уж определись

256 идет после 255, но вовсе не после 225.
В принципе, можно задействовать триггер. При вставке данных проверяешь (в триггере) количество записей. И если оно больше нужного, то просто "тупо" удаляешь одну запись.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
VeRTak
31.03.2016 - 21:16
Цитата (sergeiss @ 31.03.2016 - 21:12) |
225 или 255 записей? Ты уж определись |
ну с кем не бывает, не ту клавишу нажал

Не суть в общем скок их там
Цитата (sergeiss @ 31.03.2016 - 21:12) |
В принципе, можно задействовать триггер. При вставке данных проверяешь (в триггере) количество записей. И если оно больше нужного, то просто "тупо" удаляешь одну запись. |
Спасибо, буду сейчас смотреть в эту сторону
asstral
1.04.2016 - 14:50
А тупо: SELECT zapis FROM table ORDER BY id DESC LIMIT 255
DedMorozzz
1.04.2016 - 15:13
делай 3 запроса. Система проще и надёжнее
Только с чем связано хранение только 225и записей ? Ещё и цифра такая странная...
Спустя 56 секунд DedMorozzz написал(а):
Цитата (sergeiss @ 31.03.2016 - 20:12) |
В принципе, можно задействовать триггер |
на самом деле не ок кастыль. Бизнеслогику выносить в мускул
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
sergeiss
1.04.2016 - 16:33
Цитата (DedMorozzz @ 1.04.2016 - 15:13) |
на самом деле не ок кастыль. Бизнеслогику выносить в мускул |
Не согласен. В данном случае это нормально как раз. Тут же нет завязки на содержание, т.е. оно не изменяется в триггере.
Да и при изменении данных внутри триггера также можно поспорить

Но это уже другая тема.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Цитата (asstral @ 1.04.2016 - 14:50) |
А тупо: SELECT zapis FROM table ORDER BY id DESC LIMIT 255 |
В данный момент так и есть, но я же писал что иногда может понадобиться проделывать какие то действия к пример, нужно будет изменить у какого то пользователя кое что в бд, причем во всех сообщениях чата, если записей будет много, то я и боюсь что долго будет обрабатывать
DedMorozzz
1.04.2016 - 17:33
Цитата (Wind @ 1.04.2016 - 16:02) |
нужно будет изменить у какого то пользователя кое что в бд, причем во всех сообщениях чата, если записей будет много, то я и боюсь что долго будет обрабатывать |
Много это сколько? И зачем ты данные юзера в чатах хранишь, а не юзер айди. Или я не верно понял?
Цитата (sergeiss @ 1.04.2016 - 15:33) |
Не согласен. В данном случае это нормально как раз. Тут же нет завязки на содержание, т.е. оно не изменяется в триггере. |
удаление в тригере. во 1х не очевидная логика при рефакторинге. Такой код поддерживать сущий ад. А 2е критерий при котором происходит удаление - это и есть бизнес логика)
Тригеры ок для реалтайм бекапов юзать, а не для выноса логики приложения
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
Цитата (DedMorozzz @ 1.04.2016 - 17:33) |
Или я не верно понял? |
Не верно

Да храниться именно id пользователя, дело в том что сообщений много. В день 5-6к уников, а чат очень активный, я не отслеживал сколько за сутки поступает сообщений, но много.
Я вообще думал как вы и сказали реализовать в 3 запроса, но что то засомневался, что будет не правильно.
Спасибо, за то что развеяли сомнения
DedMorozzz
2.04.2016 - 12:38
Wind, я так понял переживаешь о месте и скорости поиска данных...
можешь сделать иначе. Поставить на крон удаление данных. Крон запускать раз в неделю
Скрипт который будет пинать крон, будет выбирать юзеров у которых больше лимита сообщений - и там подчищать последнии
Вариант 2 - намного сложнее, но лучше подходит при реально огромных объёмах данных(хотя бы от миллиона данных):
создаёшь партиции по месяцу (или какой интервал нужен). И каждый месяц запускаешь проверку, при которой очищаешь все партиции кроме текущей
truncate partition отрабатывает намного быстрее чем удаление по критериям
На выходе получишь данные за месяц-два (или необходимый интервал), а не лимит сообщений
В обоих вариантах, при каждом новом сообщении только 1 событие будет - запись. А удаление будет реализовано другой логикой
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
DedMorozzzНа счет крона уже думал. Спасибо за ответы, буду что то решать
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.