Добрый день.
Есть такая задача: существует сайт знакомств/фотоальбомов, на несколько десятков тысяч пользователей. К каждому пользователю прикручена гостевая книга - по сути таблица с несколькими полями (автор сообщения, текст сообщения, время и т.п.)
Либо, задача вторая: есть чат, в котором зарегистрировано несколько десятков тысяч пользователей. Для каждого нужно хранить его последние N приватных сообщений, которые ему выдаются при входе в чат. Тоже получается таблица - поля текст сообщения, автор, кому сообщение, время и т.п.Имеем: несколько десятков тысяч таблиц с абсолютно одинаковым набором полей. Раньше такая структура хранилась просто в файлах без базы данных. Одна таблица - один файл. Файлы раскладывались в папки по 1000 файлов в одну папку. Теперь хочется все это перенести в базу MySQL. Создавать такое огромное количество таблиц мне не кажется хорошей идеей - тем более что физически таблица занимает один или несколько файлов и все они складываются в одну папку. Можно все таблицы объединить в одну - но дело в том что получится слишком большая таблица, выборку из которой надо будет делать всегда только данных по одному пользователю - при каждом запросе перерывание слишком большого количества лишних записей.
Мне почему-то кажется такая задача довольно распространенной. Может есть для неее какое-то решение в виде создания массива таблиц в MySQL, о котором я пока не знаю.
Посоветуйте плиз. что-нить
>Посоветуйте плиз. что-нить
Задача ОЧЕНЬ тривиальна.
Поэтому я бы посоветовал почитать чего-нибудь из теории баз данных.
>>Посоветуйте плиз. что-нить
>Задача ОЧЕНЬ тривиальна.
>Поэтому я бы посоветовал почитать чего-нибудь из теории баз данных.Я базы данных уже программирую, может быть этот вопрос действительно тривиальный, но при изучении баз ну не сталкивался я с таким нигде. Большая таблица - без проблем, много таблиц - тоже можно, а специальную структуру для многих отдельных одинаковых таблиц - тут вопрос. Может направите меня по конкретной ссылочке, либо опишете подход в двух словах, и проблема разрешится очень быстро, если действительно есть тривиальное решение.
С уважением, Андрей
>>>Посоветуйте плиз. что-нить
>>Задача ОЧЕНЬ тривиальна.
>>Поэтому я бы посоветовал почитать чего-нибудь из теории баз данных.
>
>Я базы данных уже программирую, может быть этот вопрос действительно тривиальный, но
>при изучении баз ну не сталкивался я с таким нигде. Большая
>таблица - без проблем, много таблиц - тоже можно, а специальную
>структуру для многих отдельных одинаковых таблиц - тут вопрос. Может направите
>меня по конкретной ссылочке, либо опишете подход в двух словах, и
>проблема разрешится очень быстро, если действительно есть тривиальное решение.
>
>С уважением, Андрей
Да нечего мудрить особо. Создавайте одну большую таблицу и не мучайтесь. Создайте индекс по полю UserName, и тогда MySQL при запросе типаselect * from BigTable where UserName = "elvenic"
не будет перебирать все записи, а по индексу быстренько найдет и вернет именно записи для юзера "elvenic". С помощью команды 'explain select <...>' убедитесь что индекс действительно используется.
Если, к примеру в вашем чате 50000 юзеров, и для каждого хранить 1000 последних сообщений, то это всего выходит 50 млн. записей - MySQL не должен иметь проблем с такой таблицей. Только надо убедиться что файловая система на машине где таблицы хранятся не ограничивает макс. размер файла, скажем, в 2 гигабайта - а то, кажется, Linux'овая ExtFS2 имела какието похожие ограничения.
Теория: если подумать логически, то как база данных может эффективно работать с массивом таблиц как с одной таблицей? Все равно ей нужно индекс (бинарное дерево кекое-то, например) строить чтоб он охватывал все записи всех таблиц.
И как вы себе представляете работу с массивом таблиц? Сначала по имени юзера находите имя (или индекс, если мы говорим о массиве) таблицы - наверное поиском в другой таблице с учетными данными всех юзеров - а потом ищете в этой таблице? Но так вы просто вручную делаете то что база данных делает автоматически используя индексы. Не стоит ей в этом мешать.
т.е. если у меня куча разделов и во всех одинаковый наполнитель, то все это можно зафигачить в одну базу присвоив разные id(я так понял, что id можно передавать с помощью скрытого поля ввода, правильно?), и если надо вытащить в тему, то по id, а если в поиск, то по графе(ам)? все так просто, что ли?