количество строк в таблице

ИМХО MySQL не напряжется на счет и 100000 строк, тем более, что у Вас не будут объявления там лежать вечно... (стирайте не актуальные).

А на счет

к тому, что сказано topy добавлю свое имхо:

трудный путь не в создании кучи таблиц, а в создании правильных:

структура таблиц, индексация, оптимизация запросов и т.д.

topy, 100000 отлично подходит :)

буду тогда хранить собщения в одной таблице

raul21, очень с вами согласен,

индексацию, запросы оптимизировать для одной таблицы проще :)

не заморачиваюсь и остаюсь на одной таблице

спасибо за советы

вы очень помогли сделать правильный выбор

Кроме того, иногда помогает и отсуствие индексов. Это актуально при частых insert`ах и update`ах на больших базах.

По теме: по официальной информации вроде несколько десятков миллионов строк обратываются нормально.

По моему опыту хорошо спроектированная база и поиск по больше, чем 1 млн записей проходит отлично (это на обычном виртуальном хостинге). Это при том, что индексов на главной таблице нет - их убирание ускорило вставку больших прайсов в админке.

maxfx, можно не напрягаться по поводу количества строк в таблицах MySQL.

Проверено на деле. В одной из моих разработок постоянно обрабатываются дестятки миллионов строк. Там ежесуточно на каждой точке возникает от 100 тысяч записей. Чтобы было понятно - это чеки на кассовых терминалах (средняя касса пропускает за сутки около 1000 человек, средний чек - 5-7 позиций, по каждой позиции нужно отдельно сохранить данные об оплате и скидках, средний магазин - 5 касс). В месяц по каждому магазину - миллионы записей. По сети магазинов тем более... Шуршит нормально, я после этого мускул очень зауважал.

З.Ы.

Select и insert - очень быстрые операции в MySQL, delete и update - медленные. При проектировании механизмов обработки обязательно нужно учитывать эту особенность....

Вообще, читал (источник не дам - не помню, просто поверьте), проводились исследования на тему падения различных серверов баз данных, так вот из платных лучше всех показал себя Oracle, а из бесплатных, правильно, MySQL.

Одним из показателей было одновременное число запросов, Оракл выдерживал порядка 600.000, а на счет Мускуля мне понравился комментарий: "положить не удалось - предел не достигнут", вобщем написано было, что он просто начинал медленнее работать.

Всё же я отнёс бы и инсерт к медленным - при вставке, тоже идёт обновление файла индексов.

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

INSERT - это добавление данных. Обновления индексов этой операции не требуется

Спасибо я думал, что это удаление таблицы ;)

А если серъёзно, то читайте внимательно, что я написал - не обновление индексов, а обновление файла индексов. Каждая вставка - это (для таблиц MyISAM - они более популярны поэтому возьмём их, в других типах таблиц свои особенности хранения индексов) добавление данных в файл индексов, что замедляет операции вставки.

Вставка небольшого количества записей, имхо, по скорости не очень отличается от SELECT`а, но когда количество значительно, в моём случае это приводило к резкому замедлению вставки. Удалении индексов привело к резкому увеличению скорости вставки (~5-10 секунд, против 5 минут при добавлении 300-400 тысяч записей). Ещё вариант, это отключать ключи перед множественной вставкой, а затем восстанавливать их. Но в моём случае я уже точно не помню почему я не применил этот метод - уже год прошёл. Возможно, при включении индексов всё равно замедлялась работа...

Тут нужно написать, что я был не прав в своём посте ,что не уточнил, что для значительного количества записей инсерт при активных индексах становится обузой :)