FantasyDD, Давай вернёмся к началу.

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


Сколько записей предполагается хранить в таблицах users, messages ?
Примерно, важна оценка с точностью до порядка величины.

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


Как ты думаешь, какие операции в твоей БД будут затрагивать ВСЕ записи в таблице messages ?
Попробуй составить список таких операций. Или список вообще всех операций, и пометь в нём те операции, которые будут обрабатывать сразу все сообщения.

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


Для задачи "Чат" типична задача "вывести все сообщения между двумя или более пользователями" (если нет -- напиши, что тебе эта задача не нужна).

Расскажи, как ты представляешь себе решение этой задачи (можешь написать запрос для неё), если у тебя сообщения разных пользователей лежат в разных таблицах.

FantasyDDDubolom, Спасибо. У меня был опыт только под win и Firebird, печатались билеты, набранные несколькими операторами, все запихал в две таблицы, структура получилась сложной (Приведу пример = приход, разход, остаток. sql select был такой ОСТАТОК ПРЕДЫДУЩЕЙ ЗАПИСИ СКЛАДЫВАЕТСЯ С ПРИХОДОМ СЛЕДУЮЩЕЙ ВЫЧИТАЕТСЯ РАСХОД И ПИШЕТСЯ ОСТАТОК НАСТОЯЩЕЙ :) вписывал только приход и расход остаток сам рассчитывался + связные с этим таблицы ), файл базы данных работал 2 дня максимум, раздувался до огромных размеров.
После этого опыта понимаю что нужно основательно подойти к структуре и не менять лошадей на переправе.
Обязательно поделюсь своим опытом в этом проекте, если будет кому интересно.

Э... тут видимо имело значение то, какая именно СУБД это была...
Firebird -- он такой, он любит ... "раздуваться".

Я думаю, что этот конкретно твой опыт лучше всего забыть, как страшный сон, и не думать о нём более.

Я ещё раз призываю тебя сконцентрироваться на ответах на мои вопросы...


FantasyDDMasterZiv,

MasterZiv Сколько записей предполагается хранить в таблицах users, messages ?


1) users записей до 100 000 структура простая индекс ID, имя, почта, (может еще пару полей)


MasterZiv Как ты думаешь, какие операции в твоей БД будут затрагивать ВСЕ записи в таблице messages ?
Попробуй составить список таких операций.


2) Удалить пользователя со всеми диалогами, править диалоги, удалять переписку, править переписку. (Возможно будут еще задачи)



MasterZiv Расскажи, как ты представляешь себе решение этой задачи (можешь написать запрос для неё)


3) Задача чат между юзерами.
Вы пишите ко мне, ID1 обратился к ID2 у ID2 в файл сохраняется переписка в моей папке (В папке ID2 файл my_messages.db).
Вы хотите посмотреть нашу переписку. Переписку с кем? Oбращаемся ко мне в папку (D2 файл my_messages.db) если есть продолжаем, нету делаем первую запись.
Я удалил переписку, обращаетесь, нет переписки, начинаем снова.

А ваше предложение, как организовать. Или в чем может быть подвох?

Извиняюсь, нажал кнопку раньше...

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

Ещё что ты никак не можешь понять, что производительность запросов почти никак не зависит от объема данных в таблице,
при условии, что запрос использует нужные индексы. Т.е. в БД возможны такие случаи:
таблица маленькая, индексы не используются -- всё нормально

таблица маленькая, индексы используются -- всё нормально

таблица большая, индексы для запроса не используются -- запрос просто не будет работать (размер таблицы от 5-10 тыщ записей уже), и тебе придётся переделать запрос так, чтобы он использовал индексы.

таблица большая, индексы для запроса используются -- производительность запроса -- O(log N), N -- размер таблицы в кол-ве записей. Как можно догадаться, будет N равно 10 тысяч или миллиард -- разница небольшая.

Так что до миллиарда сообщений ты можешь быть относительно спокоен -- всё будет летать. Ну, хорошо, сделаем скидку на то, что это mySQL -- до десятков миллионов сообщений (на 2 порядка уменьшил).

Всё же не дописал...

ну и с учётом всего вышесказанного, напрашивается простой вывод -- разбивать таблицу на части по вертикали просто нет смысла, поскольку и так оно будет работать. Хочу также заметить, что обычно разбивают на 10-100 частей, что в принципе особого прироста скорости дать не должно. В твоём случае это было бы 100000 раз, в 100000 раз таблицы были бы меньше. Это наоборот, существенное улучшение. Но оно не нужно.

НО! если всё же ты захочешь разбить... В MySQL (как и в некоторых других СУБД) теперь есть table partitioning, таблицу физически MySQL может тебе разбивать на части, а логически это будет одна таблица, и почти все действия по организации сбора информации из многих таблиц тебе не придётся делать руками. Всё же лучше чем "палка и верёвка" из скрещения MySQL и SQLLite.

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