смотря какие именно операции будут с ней производиться

ну вот поиск уже вносит корективы ...
т.е. по сути , если просто выбирать одну строку ...то не суть важно ....
а вот если по условию, и тем более если сортировки и т.д. ...

при выборке ты берешь ток построчно ...
ну там еще смотря как кеш настроен

Отдача контента, как и редактирование по сути значения не имеет, это ж SQL. А вот поиск, групповые операции и сложные групповые запросы это да, чем больше записей в таблице, тем критичнее. С другой стороны, при поиске например, по всем разделам так и так делать union-запрос или последовательный поиск по таблицам, а это снизит скорость. Стоит обратить внимание на масштабируемость: с одной стороны разные таблицы под разделы позволяют допиливать детали _только_ нужных разделов, с другой - если разделов много, и пилить надо каждый, то править придется несколько таблиц вместо одной. В случае тотального расширения, разные таблицы проще разнести на разные сервера. Гигабайтная таблица... В принципе, это не так уж и много, но если планируется её "перебирать" тем же поиском, лучше распределить.

Учитывая, что в таблице не будет ничего лишнего, то 1 гиг и более одного только контента, то фактически много, я сужу по размерам файлов самих баз

спасибо, определился, да будет многотобличье, ди и не сложно их модернизировать

да и резервное копирование по несколькими файлами удобнее, чем тащить с сервера нечто жирное

всем спасибо :)

Drakon:

ПС: на пример, иногда можно выкрутится параллельными таблицами

тоесть?

ага, спасибо, благо место не волнует :) записал на заметку к исполнению

Есть такой опыт: 5 млн. записей на 400 метров в одной таблице (словоформы) плюс юнион на исходники при индексации работает достаточно быстро.
Думаю тут стоит логировать запросы и смотреть время их исполнения, а уж потом принимать решение.
Тот же кеш страниц вариант, ну а поиск, он всегда тяжелый и долгий...