Задача создать чат между юзерами. My SQL.
Создаю 2 таблицы messages , users .
users : Список юзеров
messages : Сообщения между юзерами.

Выходит что таблица messages в случае большой нагрузки будет ОГРОМНОЙ (все сообщения между юзерами будут в ней)
Я чувствую что в структуре ошибка! Может есть решение, как правильней организовать структуру базы данных для этой задачи (чат между юзерами).
Не создавать же новую таблицу сообщений для каждого нового юзера.

Я согласен, если юзеров 1000 (или больше) и все активные, на таблицу messages будет неимоверная нагрузка.

Dimitry SibiryakovКлиенты чата обычно хранят историю переписки локально
Если не трудно в общих чертах как это.

MasterZivFantasyDD,
Ничего не надо делать, структура нормальная. Если таблица будет большой, то тут ничего не сделаешь, и ничего плохого в этом тоже нет.

Просто у меня была подобная ситуация только с Firebird шли транзакции в одну (Все было в ней) таблицу с ~50 клиентов. Таблица за 2 дня раздувалась до пол гигобайта и начинала жутко тормозить. Я понимаю не оптимизировано. НО все равно страшно.
Может для каждого юзера папка и историю хранить там в файле. В xml, JSON, или что-то подобное.

Очень хотелось бы услышать мнение.
Если основную таблицу юзеров хранить в MySQL базе и для каждого юзера создавать папку в ней хранить переписку в Sqlite файле "sqlite_open()"
На сколько это безопасно и на что ляжет нагрузка на сервере.
Правильное ли решение на ваш взгляд?

MasterZivFantasyDDОчень хотелось бы услышать мнение.
Если основную таблицу юзеров хранить в MySQL базе и для каждого юзера создавать папку в ней хранить переписку в Sqlite файле "sqlite_open()"
На сколько это безопасно и на что ляжет нагрузка на сервере.
Правильное ли решение на ваш взгляд?
Идиотское.
Обоснуйте ответ.
Мое решение имеет основание.
1) В таком решении оптимизация не нужна. (дефрагментация.... базы )
2) Выдержит практически любое количество юзеров.

MasterZiv,
А какая связь между MySQL и Sqlite ? Зачем использовать две СУБД ?
Я не очень разбираюсь в том что происходит по капотом у MySQL но постоянные транзакции к одной таблице я думаю будут сильно фрагментировать файл таблицы.
Если создавать для каждого юзера свою таблицу. может стработать ограничение на юниксе (~ 11 000 одновременно открытых файлов)

А так по любому персональные файлы фото... будут хранится в одноименной папке юзера, почему бы не сохранить там диалоги. Файл гарантировано не будет фрагментирован. Появляется возможность легко удалить юзера. И в общих чертах все выглядит понятно.

MasterZiv, Я тебе задал вопросы.
Я ответил ели одна база то я буду вносить изменения в (большой возможно и 1G файл)
А если две базы то я вношу за сессию изменения в несколько маленьких (думаю до 1М)
В чем глупость?

MasterZivFantasyDD,

Сообщи размеры таблиц, бывший и предполагаемый. В количестве записей.

В лучшем стечении обстоятельств (не нужно исключать что повезет) mamba.ru
Аудитория проекта превысила 9 500 000 человек, более 60 000 пользователей единовременно находится онлайн

MasterZiv Может не стоит фантазировать на тему как мне дать замечание и терять зря свое время на бесполезный фулд.
А если есть свое мнение высказаться конкретно по теме.

MasterZiv С удовольствием выслушал бы ваше мнение. (Мнение профессионала)
Но не то что я зря теряю время и что мне не надо делать то что я не умею или не знаю.
Какое решение вы предлагаете? В чем будут проблемы в той структуре что я предложил (2 базы).
Где ждать подводные камни в этом решении?

И с чего вы взяли, что склайт-базёнки не будут фрагментироваться, если уж начать бредить в этом направлении?

В одном фале последовательно сложить 500 текстовых сообщений, не удаляя нечего. Где фрагментация? В чем бред?