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

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

если на сервере только голый html - понятное дело, что никаким дополнительным кешированием заморачиваться не надо

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

в общем я за php+mysql+кеширование

у ТС 10-30 тысяч страниц

ИМХО, файлы радовать не будут

в поставленной задаче это излишне. если ТС не дополнит свои потребности.

а, кстати, кэширование где? на каком уровне? ;) то бишь, какое? :) (мне можно не отвечать)

он что-то говорил про какую-то CMS.... может на Перле, или на php... или на Jave, а может на C++, или даже, упаси господи, на Delphi :)

cms пишу на пхп. Я просто цмс для такого количества данных еще не писал, вот и задумался производительности и целесообразности разных вариантов.

Спасибо огромное всем за ответы.

мускул и кэширование в файлы. места больше займет в два раза, зато удобство работы, возможность расширения.

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

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

согласен с вашим постом.

размер статьи?

если статьи довольно большие (от 2-5Мб), то может быть будет лучше отдавать как статику, может PgSQL+nginx

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

как на счет полнотекстового поиска? (хотя MySQL, тоже будет не лучший вариант)

если на файлах: ядро ОС будет тратить много ресурсов на то чтобы открывать эти файлы, можно попробовать кэшировать дескрипторы файлов (есть в nginx), размещать статьи в виде кэша, а не в одном каталоге 100к файлов! (100к файлов - это уже очень плохо)

попробовать может быть файловую систему какую-то там FastFS

если не хватит ресурсов сервера, можно СУБД реплицировать на несколько серверов и балансировщик httpd поставить на эти сервера, который будет отдавать...

кстати, есть связка MogileFS+Perlbal (протестированная на миллионы пользователей) для отдачи файлов с распределенного многоуровневого хранилища

вообще-то мало информации в первом посте, так что как говорится фигня будет и так и так 😂

я бы попробовал PosgreSQL, но можно любую связку

оптимальное решение это mysql + php,

не вижу никакого смысла хранить 10-30 тыс файлов... так как организовать быстрое файловое хранилище с удобствами, какие предлагает mysql гораздо сложнее чем использовать базу,

далее сам mysql кэширует запросы, по этому если у вас там посещаемость будет до 5 тыс думаю вообще про нагрузку не стоит париться...

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

по этому мое мнение mysql+php и даже на другие варианты я бы не тратил время для рассмотрения

Однозначно php + MySQL.

Правильный подход: движок - отдельно, система хранения и доступа к данным - отдельно. И не надо писать эту "систему доступа к данным " самому - MySQL справится с хранением, обеспечением целостности данных и скоростью доступа на порядок лучше, чем Ваш самописный код + файловая система.

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

Это сейчас никаких примочек, а завтра вам потребуется сделать внутреннюю перелинковку по ключам, или поиск на сайте - и как? Будете каждый раз шариться по 30 тыс файлов?

Если надо, имея движок на php+MySQL можно всегда выгрузить сайт в виде голого HTML - повесив функции ob_start() + ob_get_content() + file_put_contents(), и залить его на любой хостинг.

Если уж пишете движок сами - делайте сразу правильно.

Alex Klo говорит правильные вещи и приводит разумные доводы, но не забывайте, что:

И ещё - Alex Klo знает и умеет много страшных слов:

, поэтому то, он легко и оптимально может реализовать на файловой системе, Вы - не сможете с помощью одного лишь PHP, особенно в условиях ограниченного доступа к серверу на хостинге.

PS: С файловой системой тоже есть подводные камни - одновременный доступ на чтение запись, кэширование системой запросов к FS и тп.

ТС, поищите по форуму, за последние пол года таких тем (файлы или БД) было штук 5 на моей памяти.