Как лучше хранить переписку между пользователями?
всем привет. подскажите как лучше хранить переписку между саппортом и пользователями?
подойдет ли такая структура —
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, если что.
В как лучше хранить конечный список?
Добрый день. Задача такая. Допустим у меня есть товар, который его привозят с разных уголков.
Как лучше хранить ведомости (журнал класса)?
Как лучше хранить ведомость типа журнал класса с промежуточными оценками? Понятно, что обязательны.
[Теоритическая часть] Как лучше хранить картинки
Есть интернет-магазин, нужно как-то хранить картинки к товарам. Их будет много, и они будут каждый.
Как лучше хранить данные в таблице для блога?
Здравствуйте. Подскажите пожалуйста как лучше поступить: Есть таблица для хранения новостей блога.
Проектируем систему сообщений в стиле 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
Просмотров: 33678
Правила перепечатки
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 сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.
хранение сообщений чата для приложения чата на бэкэнде
так что у меня нет решения, пожалуйста, предложите мне какое-нибудь решение, и я новичок на форуме, так что будьте терпеливы к моим глупым ошибкам и к тому, как большие рыбы любят fb, какое приложение хранит свои сообщения>
Ответы (2)
Из трех вариантов для этого я бы выбрал ваш первый вариант (часть а), если вы имели в виду реляционную БД (например, mysql). Размер базы данных увеличится, если вы сохраните все. Тем не мение. Нужно ли хранить все? Один из вариантов — периодически удалять старые сообщения.
Моим предпочтительным вариантом на самом деле была бы база данных документов nosql для этого (что-то вроде mongo), поскольку вам, вероятно, не нужно будет моделировать какие-либо сложные реляционные данные. Затем я бы смоделировал каждый «чат» как документ. Каждый чат будет иметь массив сообщений. Таким образом, каждый раз, когда приходит новое сообщение, вы отправляете его в массив сообщений для соответствующего чата. Я бы также рассмотрел возможность архивации старых сообщений в массиве, если бы я ожидал, что чаты будут сохраняться в течение длительного времени или генерировать много данных.
После того, как я сделал это, если бы скорость все еще была проблемой, я бы посмотрел на добавление кэширования памяти (memcached или apcu или оба). Все сообщения будут публиковаться и извлекаться из кеша, поэтому любые популярные чаты останутся в памяти, что даст вам хороший прирост скорости.
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.