Всем привет, имеется мини чат.
1) - Выводим сообщения
2) - Если пользователь пишет сообщение, естественно добавляем его
Нужно хранить только 225 записей, Не могу додумать как реализовать, я думаю тут какой то надо не простой sql запрос наверное или же какие то другие пути? Я вообще думал после добавления сообщения, смотреть сколько вообще есть записей в бд и удалять ненужные, и того получается 3 запроса, или так и должно быть?
В таком случае какой тип лучше дать таблице?
Полная Версия: Хранить только 225 записей в базе
Подумай в сторону разделения:
1. пока чат активен все записи пишутся в tmp табличку.
2. как только чат закончен, записи из tmp переносятся в архив.
Вот во время переноса уже можешь проводить все нужные манипуляции , т.к. это будет фактически разовая операция по сравнению с отправкой данных из активного чата.
1. пока чат активен все записи пишутся в tmp табличку.
2. как только чат закончен, записи из tmp переносятся в архив.
Вот во время переноса уже можешь проводить все нужные манипуляции , т.к. это будет фактически разовая операция по сравнению с отправкой данных из активного чата.
icedfox
Так он активен всегда. Или я что то не так понял под словом активен?
Мне вот что нужно при добавлении 256 сообщения в чат что бы 1-го не было в бд.
Может я зря переживаю, просто чат самое активное место, при 5-6к уников в сутки, не мало сообщений попадаем в чат, там стоит лимит на 255 записей ну 15 записей на страницу. Бывает такая ситуация что нужно у определенно id юзера поменять кое что во всем чате. Если будет 225 записей то проблем не будет, а если миллионы записей, ничего не захлебнется там?
Так он активен всегда. Или я что то не так понял под словом активен?
Мне вот что нужно при добавлении 256 сообщения в чат что бы 1-го не было в бд.
Может я зря переживаю, просто чат самое активное место, при 5-6к уников в сутки, не мало сообщений попадаем в чат, там стоит лимит на 255 записей ну 15 записей на страницу. Бывает такая ситуация что нужно у определенно id юзера поменять кое что во всем чате. Если будет 225 записей то проблем не будет, а если миллионы записей, ничего не захлебнется там?
225 или 255 записей? Ты уж определись 
256 идет после 255, но вовсе не после 225.
В принципе, можно задействовать триггер. При вставке данных проверяешь (в триггере) количество записей. И если оно больше нужного, то просто "тупо" удаляешь одну запись.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
256 идет после 255, но вовсе не после 225.В принципе, можно задействовать триггер. При вставке данных проверяешь (в триггере) количество записей. И если оно больше нужного, то просто "тупо" удаляешь одну запись.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата (sergeiss @ 31.03.2016 - 21:12) |
| 225 или 255 записей? Ты уж определись |
ну с кем не бывает, не ту клавишу нажал
Не суть в общем скок их там| Цитата (sergeiss @ 31.03.2016 - 21:12) |
| В принципе, можно задействовать триггер. При вставке данных проверяешь (в триггере) количество записей. И если оно больше нужного, то просто "тупо" удаляешь одну запись. |
Спасибо, буду сейчас смотреть в эту сторону
А тупо: SELECT zapis FROM table ORDER BY id DESC LIMIT 255
делай 3 запроса. Система проще и надёжнее
Только с чем связано хранение только 225и записей ? Ещё и цифра такая странная...
Спустя 56 секунд DedMorozzz написал(а):
Только с чем связано хранение только 225и записей ? Ещё и цифра такая странная...
Спустя 56 секунд DedMorozzz написал(а):
| Цитата (sergeiss @ 31.03.2016 - 20:12) |
В принципе, можно задействовать триггер |
на самом деле не ок кастыль. Бизнеслогику выносить в мускул
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
| Цитата (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 |
В данный момент так и есть, но я же писал что иногда может понадобиться проделывать какие то действия к пример, нужно будет изменить у какого то пользователя кое что в бд, причем во всех сообщениях чата, если записей будет много, то я и боюсь что долго будет обрабатывать
| Цитата (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 запроса, но что то засомневался, что будет не правильно.
Спасибо, за то что развеяли сомнения
Wind, я так понял переживаешь о месте и скорости поиска данных...
можешь сделать иначе. Поставить на крон удаление данных. Крон запускать раз в неделю
Скрипт который будет пинать крон, будет выбирать юзеров у которых больше лимита сообщений - и там подчищать последнии
Вариант 2 - намного сложнее, но лучше подходит при реально огромных объёмах данных(хотя бы от миллиона данных):
создаёшь партиции по месяцу (или какой интервал нужен). И каждый месяц запускаешь проверку, при которой очищаешь все партиции кроме текущей
truncate partition отрабатывает намного быстрее чем удаление по критериям
На выходе получишь данные за месяц-два (или необходимый интервал), а не лимит сообщений
В обоих вариантах, при каждом новом сообщении только 1 событие будет - запись. А удаление будет реализовано другой логикой
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
можешь сделать иначе. Поставить на крон удаление данных. Крон запускать раз в неделю
Скрипт который будет пинать крон, будет выбирать юзеров у которых больше лимита сообщений - и там подчищать последнии
Вариант 2 - намного сложнее, но лучше подходит при реально огромных объёмах данных(хотя бы от миллиона данных):
создаёшь партиции по месяцу (или какой интервал нужен). И каждый месяц запускаешь проверку, при которой очищаешь все партиции кроме текущей
truncate partition отрабатывает намного быстрее чем удаление по критериям
На выходе получишь данные за месяц-два (или необходимый интервал), а не лимит сообщений
В обоих вариантах, при каждом новом сообщении только 1 событие будет - запись. А удаление будет реализовано другой логикой
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
DedMorozzz
На счет крона уже думал. Спасибо за ответы, буду что то решать
На счет крона уже думал. Спасибо за ответы, буду что то решать
Здесь расположена полная версия этой страницы.