SQL vs статический HTML

[iluxa3650 0]

Вопрос мой, а скорее приглашение к дискусии звучит так:

Например есть сайт, возможно на DLE. Контент сайта представляет собой статьи (рассказы, стихи и т.д.). Объем текста от 5 до 200 килобайт, в среднем 30-40кб. А теперь вопрос: что лучше, сделать для каждого текста (статьи, расказа) - новость, чтобы каждое прочтение пользователем выгружало из базы SQL эти 30-40 кб., или каждую новость оформить в HTML файле (если например сайт не на DLE), либо подгружать через тот же SSI? Тогда как будут вести себя дерективы include в теле новости? "Лучше" это конечно расплывчатый параметр, интересует:

- нагрузка на SQL при таких объемах текста

- при каком варианте скорость загрузки сайта больше

- ну и другие моменты по удобству, расширяемости и др.

Еще один вопрос: при использовании в DLE разбиения статьи на страницы (например по 10кб текста на страницу), запрос к SQL выгружает только нужную часть или все, а скрипт php уже вырезает нужное? Если первый случай, то ценность варианта с SQL резко возрастает, т.к я опасаюсь за высокую нагрузку на SQL сервер.

Еще надо упомянуть что статей около 9000!

Заранее спасибо за ответы!

Изменено 6 апреля 2008 пользователем iluxa3650

[celsoft 6 081]

Еще надо упомянуть что статей около 9000!

это ответ на все ваши вопросы, создайте вручную 9000 HTML страниц, потом чтобы что изменить в дизайне отредактируйте 9000 файлов. Я понимаю что когда страниц например 10, то есть смысл сверстать 10 HTML страниц.

[lifestar 18]

SQL vs статический HTML

лучше SQL + кеширование

[iluxa3650 0]

SQL vs статический HTML

лучше SQL + кеширование

Вы уже второй кто это предлагает. Это сложно реализовать для DLE? И как будет вести себя сервер если на нем создаться более 50000 файлов кеша (9000 статей по 5 страниц в среднем)? Если я конечно правильно понимаю кеширование.

[lifestar 18]

при использовании в DLE разбиения статьи на страницы (например по 10кб текста на страницу), запрос к SQL выгружает только нужную часть или все, а скрипт php уже вырезает нужное? Если первый случай, то ценность варианта с SQL резко возрастает

как раз таки случай №2, поэтому может не имеет смысла разбивать на страницы?

Это сложно реализовать для DLE?

вовсе нет, более того - отчасти уже реализован.

как будет вести себя сервер если на нем создаться более 50000 файлов кеша

конечно если эти файлы будут лежать в одной папке - плохо, если в разных - ничего страшного. Будет работать на ура. И опять же повторюсь: может не имеет смысла разбивать на страницы? Тогда и файлов кеша будет меньше

[iluxa3650 0]

как будет вести себя сервер если на нем создаться более 50000 файлов кеша

конечно если эти файлы будут лежать в одной папке - плохо, если в разных - ничего страшного. Будет работать на ура. И опять же повторюсь: может не имеет смысла разбивать на страницы? Тогда и файлов кеша будет меньше

Причин постраничной прокрутки несколько:

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

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

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