Передо мной стоит задача: Написание модуля создания страниц.
Т.е. допустим есть страницы с новостями; Диалогами и пр. Пользователю нужно создать статическую страницу, к примеру, с контактами. Как сделать подобный модуль? Есть идея запилить папочку pages и в ней создавать php страницы и в static/pages/* ставить html шаблоны страниц. Но как реализовать запиливание страниц php по шаблону там: (<?php $cont = ... ?> и выставлять значения переменных в этом шаблоне динамически (после заполнения форм).
Второй вариант: создаю файл: modules/pages/index.php
в GET получаю номер страницы и вывожу соответствующий файл.
Эм, я конечно немного не понял что именно ты хочешь, но разве нельзя сделать таблицу в БД с контентом статическим и выводить его оттуда. Вообщем... я делал так:
Таблица : content:
id, name, rus_name, html, php
ну вот как r00t_san рассказал, так обычно и делается.
Лишняя угроза. Если есть возможность удобно обходиться с только файлами, то их и юзаю. Ибо с базой можно упустить моменты, да и зачем грузить базу лишним? Хотя со стороны веса и бекапов, в базе хранить безопасней....
В принципе, на файлах легко хранить. Но тут не забывай, что файл (если он будет редактируемым) смогут открыть одновременно 2 пользователя. И есть шанс, что они одновременно его сохранят (маленький, маленький, но все же шанс!) и тогда неизвестно к каким последствиям приведет это. В базе же есть очередность и сколько бы запросов к ней не было, они никогда не пересекутся, чего не скажешь о файлах.
В принципе, на файлах легко хранить. Но тут не забывай, что файл (если он будет редактируемым) смогут открыть одновременно 2 пользователя. И есть шанс, что они одновременно его сохранят (маленький, маленький, но все же шанс!) и тогда неизвестно к каким последствиям приведет это.
Элементарно решается путем создания объекта, символизирующего о блокировке (например, самый простой вариант - файл, под виндой и линуксом можно семафоры использовать и т.п.). Правда, тогда второй записывающий кусок будет подвисать до тех пор, пока первый не удалит объект блокировки, но это незначительные задержки. Хуже то, что в случае ошибки в программе, если объект блокировки не удалится - никто писать не сможет.
Скажу что я думаю по этому поводу. Все ИМХО, но тем не менее подкрепленное опытом.
Если инфы мало и она очень часто редактируется, например при каждом обращении к странице сайта, то лучше юзать файлы. Приведу пример такой инфы:
счетчики посещений
кто онлайн
кто просматривает данный форум
временные файлы антидоса, которые создаются при каждом обращении к любой странице
и т.д.
А в базе данных нужно хранить ту инфу, которая относительно редко изменяется и является критической.Критической? Ну да, критической - той которая нужна для сайта и для его работоспособности. Почему же такую информацию лучше хранить в базе? По тому что, если ты сделаешь дамп базы, то у тебя в нем будет вся важная инфа. А если она в файлах, то кроме дампа базы, придется еще постоянно делать дамп файлов.
И я бы не парился о том что будет лишний запрос к базе, в крайнем случае можно поставить кэш и если страница не менялась и есть кэш, то она будет отдаваться из кэша. Если же в кэше ее нет, то сделается запрос к базе и закэшируется, что бы в дальнейшем брать ее из кэша. То есть потери времени особо никакой.
Я тоже очень интересовался нагрузкой на базу данных и выяснил для себя, что она ничтожно мала, по сравнению работы того же Apache в связке с php. У себя (в коэс 1.6 ) реализовал систему достижений, систему клановой прокачки, новую денежную систему и многое другое. Так вот в секунду идет около 1 запроса от игрока, на 5 серверов это 150 запросов в секунду. Запросы небольшие, вроде TINYTEXT и int(10). И нагрузка на базу выходит просто мизерной: около 2-5% на процессор в пик своей загруженности.
В том то и дело, что модуль снипетов и чанков уже реализован. И реализован базой.
Я реализовывал создание статических страниц. Типа контакты и прочая хуетень. Реализовал базой. Адаптация к чанкам и сниппетам затруднений не вызвала. Отшлифую модуль на старой cms и перенесу на новую.