Целесообразно ли использовать MySQL

в вашем случае мускул - явно лишнее.

вопрос только в том как вы будете готовить эти 10к-30к страниц (мускул тут ни при чём.)

З.Ы. Поясню: мускул - это среднее звено между файловым хранилищем вебсервера и отдаваемым клиенту html'ем.

мускул нужен тогда, когда необходимо вести базу данных (тут можно много говорить зачем это нужно...).

Спасибо, тоесть для меня получается хранить данные в файлах идеальный вариант? Какие-нибудь еще варианты имеются?

Это все продумано. Как раз вот встал вопрос в хранении таких количеств страниц.

del.......

в чем вопрос-то? раскидать по каталогам... и делов-то... по 100-200 страниц на каталог...

/topic1/glava1/

/topic1/glava1/page1.htm

/topic1/glava1/page2.htm

...

/topic1/glava1/pageN.htm

/topic1/glava2/

...

/topic1/glavaN/

...

/topic2/glava1/

/topic2/glava2/

...

/topic2/glavaN/

Вас не устраивает идеальный вариант? ;)

Ну, если хотите, то можно все 10К-30К страниц хранить в файле ворда на хостинге и оттуда изымать в html при каждом обращении пользователя... :)

или Вам нужен WP, Joomla или другая нынче модная у школьников хрень?

даже динамический сайт с кучей журналюг, постящих каждую минуту свои статейки на сайт можно реализовать без мускула, а, например, с помощью php, cgi, Perl и т.д. ... но это тема отдельного разговора...

Нет-нет, я не это имел в виду. Можно же все хранить в базе мускула. Ну и скриптом оттуда вытаскивать в зависимости от параметров.

А можно хранить в файлах и также скриптом оттуда вытаскивать. Вот и выбирал между ними. Ладно, спасибо за помощь.

а зачем тут скрипт? скрипт может быть нужен только чтобы положить в файл, а сам файл-то - page.html при наличии ссылки на него уже будет сам работать...

небольшой тест:

публикация страниц будет каждую минуту?

нет? - вам не нужна база данных

публикуемая страница будет проходить на проверку валидности, орфографии, наличие/отсутствия чего-то в ней?

нет? - вам не нужен серверный скрипт (php, perl и т.д.).

Итог: если сайт типа - залил и забыл (иногда поправил) - не нужно ни MySQL, ни php (и аналоги). Этим достигается надежность и быстродействие.

При этом используется http: ftp: html SSI. Всё.

10-30k страниц сейчас

потом захочется добавить метки (tags) или еще какую плюшку

перелопачивать 10-30k файлов, мягко говоря, не удобно (ИМХО)

бэкапить mysql базу, опять таки ИМХО, значительно удобнее и проще (нет гемора с правами на запись и листинг директории с большим кол-вом файлом иногда :) штука неприятная, да и целостность бэкапа большого кол-ва файлов не всегда гарантируется)

решение: пользовать mysql для удобства и надежности

пользовать файловое кеширование для увеличения производительности (если будет не хватать - копать в сторону memcached)

конечно! но для этого не нужен MySQL или php, и они не помогут.

достаточно предусмотреть в шаблонах html и в содержании страниц такую возможность. А реализуется она с помощью SSI (.shtml). Правда именно тут можно использовать php.

она гарантируется автором - на своём HDD и т.д.

кешировать страницу page.html ? 😮 (вообще-то зачем? и броузер это делает и хостинг...)

хороший хостер это гарантирует, а если это не работает у других - надо менять хостинг, но я таких сегодня не представляю... ну если только домашний хостинг...

Кстати, напоминаю, ТС спрашивал, что надежнее и быстрее.

Что может быть надежнее и быстрее голого html от вебсервера хостинга к броузеру пользователя?

Только мысль... :) или почта России? :) DHL? Western Union? :D

как Вы с помощью ssi найдете ключевые слова в статьях и присвоите статье, на основе этих ключевых слов, определенный тег?

моя практика показывает, что качание большого кол-ва файлов по ftp на винт может сопровождаться сбоем процесса и в следствии этого какой-то файл (если сбоев несколько, то следовательно несколько файлов) будет битым (докачка не всегда срабатывает как ожидается)

+ если на файле стоит право на запись, то скачав по ftp этот файл себе на win машину, вы это право потрете (в винде автоматом будет право на запись, а вот если закачивать этот файл на новый хостинг, то прийдется заново ставить право на запись ибо по дефолту будет "только чтение")

кешировать результаты выполнения скрипта (php, perl), запросов к БД (запросили у mysql текст статьи, автора и прочие данные - сформировали блок "статья" - сохранили в файл, при повторном запросе страницы с этой статьей - берете данные из сформированного (кешируемого в файл) блока, а не заново мучаете mysql)

я поэтому и сказал: php (но в случае ТС этого, похоже, не надо)

я с таким не встречался, и не думаю, что это частая ситуация

и зачем page.html какие-то недефолтные права?

к чему это всё? (всё это обеспечивается хостингом, цепочкой прокси-серверов от хостинга к клиенту, броузером)

если у ТСа просто голые html страницы?

какое кеширование запросов? у него же не форекс!

я и говорю - mysql нам не нужен... как и скрипач в Кин-Дза-дза...:)

mysql автоматом тэги тоже не сформирует - для этого нужны некие действия..., которые при начальном планировании можно предусмотреть и на уровне html и php.

Mitos, я рассуждаю в пределах поставленной ТС задачи... вообще - может быть куча вариантов...