Как лучше хранить переписку между пользователями?
всем привет. подскажите как лучше хранить переписку между саппортом и пользователями?
подойдет ли такая структура —
supports (id, name);
clients (id, support_id, name);
messages (support_id, client_id, direction, text);
не начнутся ли тормоза при большом кол-ве данных в таблице messages при выборках?
или же есть более лучшие варианты?
где-то читал что проще и лучше использовать базы nosql типа redis и хранить переписки между людьми в одной ячейки в виде списков, коллекций или json?
что посоветуете?
Как лучше хранить данные
В одной таблице или нет? есть 1) 50мил.строк 2) каждая строка занимает 3кб (т.е. выходит.
Как лучше хранить данные
Здравствуйте, у меня есть лист товаров, каждый из них может иметь разные способы доставки. Как это.
Как лучше хранить товары в БД?
Добрый день. Скажите, плз, кто знает, как лучше хранить товары в БД? Товары разбиты на категории.
Как лучше хранить сообщения в БД?
как лучше хранить принятые и отправленые сообщения в одной БД или в разных БД . БД очень большая.
JSON будет еще хуже. Хранили мы данные в Mongodb на похожем проекте. Монга умерла когда было 2 млн записей. MySQL + InnoDB + заточка my.cnf под InnoDB + SSD и 2 гигабайта ОЗУ сейчас хранит 40 млн+ записей, которые постоянно добавляются без каких либо проблем.
Вам нужно копать не в ту сторону. Оптимизируйте MySQL под InnoDB, добавляйте память, расставляйте ключи и загоните туда 100 млн строк, а потом уже смотрите. Не будет ничего тормозить, если не будет в запросах по 5 JOIN. В вашей структуре с расставленными ключами все будет окей.
А если у вас будет до 10 млн, то можно и не оптимизировать ничего. Все и так будет работать. Но повторюсь, скорость зависит прежде всего от сервера.
Nosql лично я не рассматриваю по причине хайпа в 2015году на них, а сейчас этот хайп уже спал и кто его знает, что будет дальше? А SQL никуда не денется. Кстати в VK MySQL, если что.
В как лучше хранить конечный список?
Добрый день. Задача такая. Допустим у меня есть товар, который его привозят с разных уголков.
Как лучше хранить ведомости (журнал класса)?
Как лучше хранить ведомость типа журнал класса с промежуточными оценками? Понятно, что обязательны.
[Теоритическая часть] Как лучше хранить картинки
Есть интернет-магазин, нужно как-то хранить картинки к товарам. Их будет много, и они будут каждый.
Как лучше хранить данные в таблице для блога?
Здравствуйте. Подскажите пожалуйста как лучше поступить: Есть таблица для хранения новостей блога.
Best way to store chat messages in a database? [closed]
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago .
I’m building a chat app and I want a full history off all messages ever sent in the chat conversation. At the moment I am storing each message as a single row in a table called ‘messages’. I am aware that this table could grow huge as even small messages like ‘Hi’ would have their own database record.
Can anyone recommend a more scalable mysql solution? I don’t require the individual messages to be searchable, editable or deletable. Could the whole conversation be stored in one huge field?
Would love to hear your ideas!
3 Answers 3
There’s nothing wrong with saving the whole history in the database, they are prepared for that kind of tasks.
Actually you can find here in Stack Overflow a link to an example schema for a chat: example
If you are still worried for the size, you could apply some optimizations to group messages, like adding a buffer to your application that you only push after some time (like 1 minute or so); that way you would avoid having only 1 line messages
If we assume that you do not read the data too.
This sounds to me like an audit\logging requirement, if it is, you do not need a database to store the chat messages.
Just append the conversation to a text file (1 file per day?). The file could look like this:
I think you will find it hard to get a more simple scaleable audit solution.
If your requirements change and you need to search\edit\delete then a database would be more appropriate.
You could create a database for x conversations which contains all messages of these conversations. This would allow you to add a new Database (or server) each time x exceeds. X is the number conversations your infrastructure supports (depending on your hardware. ).
The problem is still, that there may be big conversations (with a lot of messages) on the same database. e.g. you have database A and database B an each stores e.g. 1000 conversations. It my be possible that there are far more «big» conversations on server A than on server B (since this is user created content). You could add a «master» database that contains a lookup, on which database/server the single conversations can be found (or you have a schema to assign a database from hash/modulo or something).
Maybe you can find real world architectures that deal with the same problems (you may not be the first one), and that have already been solved.
Проектируем систему сообщений в стиле Facebook
В этом посте мы постараемся разобраться, как организовать систему общения между пользователями в стиле Facebook.
Структура БД
Для данной системы нам понадобится всего три таблицы: Users, Conversation и Conversation_Reply.
Таблица пользователей
В данной таблице должна храниться вся информация о зарегистрированных пользователях.
Данный будут храниться в следующем виде; пароль должен хешироваться с помощью md5.
Таблица диалогов
Данная таблица хранит информацию о диалогах пользователей. Поля user_one и user_two являются внешними ключами к полю users.user_id.
Система ответов
Содержит все ответы на сообщения пользователей. Тут user_id_fk — это внешний ключ к полю users.user_id; и c_id_fk — внешний ключ для поля conversation.c_id
Списки далогов
Тут используем отношения таблиц users и conversation. К таблице users будем обращаться по алиасу U, а к conversation по алиасу C . В данном листинге user_one = ’13’ и user_two=’13’ относятся к таблице users и значению поля user_id.
Последние сообщения диалога
Выводим содержимое ответов на диалог с c_id=’2′ из таблицы conversation_reply.
Выводим все диалоги пользователя arun:
Обновление диалога
Используем отношение между таблицами и users и conversation_reply. К таблице users будет обращаться по алиасу U, а к conversation_reply по алиасу R . В данном листинге c_id_fk = ‘2’ относится к таблице convesation и значению поля c_id.
Обновление диалога
Используем отношение между таблицами и users и conversation_reply. К таблице users будет обращаться по алиасу U, а к conversation_reply по алиасу R . В данном листинге c_id_fk = ‘2’ относится к таблице convesation и значению поля c_id.
Показать сообщения диалога с c_id=2.
Проверка существования диалога
Следующий запрос проверяет наличие диалога.
Создание диалога
Вставка ответа
Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: http://www.9lessons.info/2013/05/message-conversation-database-design.html
Перевел: Станислав Протасевич
Урок создан: 17 Сентября 2013
Просмотров: 33718
Правила перепечатки
5 последних уроков рубрики «PHP»
Фильтрация данных с помощью zend-filter
Когда речь идёт о безопасности веб-сайта, то фраза "фильтруйте всё, экранируйте всё" всегда будет актуальна. Сегодня поговорим о фильтрации данных.
Контекстное экранирование с помощью zend-escaper
Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.
Подключение Zend модулей к Expressive
Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.
Совет: отправка информации в Google Analytics через API
Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.
Подборка PHP песочниц
Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.
Лучший способ хранить сообщения чата в базе данных?
Я создаю приложение для чата, и я хочу, чтобы полная история удалялась из всех сообщений, когда-либо отправляемых в чате. В настоящий момент я сохраняю каждое сообщение в виде одной строки в таблице, называемой «сообщениями». Я знаю, что эта таблица может стать огромной, поскольку даже небольшие сообщения типа «Привет» будут иметь собственную запись базы данных.
Может ли кто-нибудь рекомендовать более масштабируемое решение mysql? Я не требую, чтобы отдельные сообщения были доступны для поиска, редактирования или удаления. Может ли весь разговор храниться в одном огромном поле?
Хотелось бы услышать ваши идеи!
3 ответа
Нет ничего плохого в сохранении всей истории в базе данных, они готовы к таким задачам.
На самом деле вы можете найти здесь в Qaru ссылку на примерную схему для чата: пример
Если вы все еще беспокоитесь о размере, вы можете применить некоторые оптимизации для группировки сообщений, например, добавить буфер в приложение, который вы только нажимаете через некоторое время (например, 1 минуту или около того); таким образом, вы избегаете иметь только 1 сообщение строки
Если вы можете избежать необходимости одновременной записи в один файл, это звучит так, как будто вам не нужна база данных для хранения сообщений чата.
Просто добавьте конвертацию в текстовый файл (1 файл на пользователя\разговор).
Вам тогда нужно будет только сохранить идентификатор пользователя, идентификатор беседы и ссылку на имя файла.
Я думаю, вам будет трудно получить более простое масштабируемое решение.
Если у вас есть требование перестроить разговор, вам нужно будет добавить значение вместе с отправленным сообщением чата (в файле), чтобы вы могли объединять и сортировать файлы.
Вы можете создать базу данных для x цепочек, содержащих все сообщения этих цепочек. Это позволит вам добавлять новую базу данных (или сервер) каждый раз, когда х превышает. X — количество разговоров, поддерживаемых вашей инфраструктурой (в зависимости от вашего оборудования. ).
Проблема по-прежнему заключается в том, что в одной базе данных могут быть большие разговоры (с большим количеством сообщений). например у вас есть база данных A и база данных B, каждая из которых хранится, например. 1000 разговоров. Возможно, что на сервере A гораздо больше «больших» разговоров, чем на сервере B (так как это созданный пользователем контент). Вы можете добавить «основную» базу данных, содержащую поиск, на основе которой можно найти одиночные разговоры (или у вас есть схема для назначения базы данных из хэша/модуля или чего-то еще).
Возможно, вы можете найти архитектуры реального мира, которые занимаются одними и теми же проблемами (возможно, вы не первый), и это уже было решено.