Хорошая идея, успехов в развитии
я вот пока с подобной штукой все никак от этапа "думаю" не отойду :(
Как цвет влияет на покупателя
если будет не сильно офтопиком - может кто-то пояснить моду ставить в 17шки два HDD винта (например, 500Гб+500Гб), вместо одного (1Тб) или вообще вместо комбинации SSD(128-256Гб, с возможностью легко заменить, когда сдохнет; для системы и т.п.)+HDD(1Тб, для фильмов и прочего тяжелого)
прикольные человечки
http://maps.yandex.ru/-/CBQIfM3Q
имея свой проц. центр в России Visa не узнает зарплату слесаря Васи?
в Киеве, если не путаю, при открытии Metro тоже народ с ума сходил из-за бесплатной бутылки шампанского
что б иметь возможность обновить его (например, когда будет добавлен новый материал), если, конечно, обновление не будет происходить путем закачки по ftp нового, вручную отредактированного, файла (в этом случае поддержка 10-30k страниц будет довольно веселым занятием :) )
если на сервере только голый html - понятное дело, что никаким дополнительным кешированием заморачиваться не надо
проблема только в том, что этот голый html скорее всего прийдется как-то поддерживать в будущем (обновлять при добавлении нового материала, добавлять новые фичи...)
в общем я за php+mysql+кеширование
у ТС 10-30 тысяч страниц
ИМХО, файлы радовать не будут
как Вы с помощью ssi найдете ключевые слова в статьях и присвоите статье, на основе этих ключевых слов, определенный тег?
моя практика показывает, что качание большого кол-ва файлов по ftp на винт может сопровождаться сбоем процесса и в следствии этого какой-то файл (если сбоев несколько, то следовательно несколько файлов) будет битым (докачка не всегда срабатывает как ожидается)
+ если на файле стоит право на запись, то скачав по ftp этот файл себе на win машину, вы это право потрете (в винде автоматом будет право на запись, а вот если закачивать этот файл на новый хостинг, то прийдется заново ставить право на запись ибо по дефолту будет "только чтение")
кешировать результаты выполнения скрипта (php, perl), запросов к БД (запросили у mysql текст статьи, автора и прочие данные - сформировали блок "статья" - сохранили в файл, при повторном запросе страницы с этой статьей - берете данные из сформированного (кешируемого в файл) блока, а не заново мучаете mysql)
10-30k страниц сейчас
потом захочется добавить метки (tags) или еще какую плюшку
перелопачивать 10-30k файлов, мягко говоря, не удобно (ИМХО)
бэкапить mysql базу, опять таки ИМХО, значительно удобнее и проще (нет гемора с правами на запись и листинг директории с большим кол-вом файлом иногда :) штука неприятная, да и целостность бэкапа большого кол-ва файлов не всегда гарантируется)
решение: пользовать mysql для удобства и надежности
пользовать файловое кеширование для увеличения производительности (если будет не хватать - копать в сторону memcached)
может конвульсии ПО статистики после того как кто-то из пользователей "побаловался" с вводом? :)
