Конфиг CMS, идея реаллизации хочу узнать мнения

[Nelius]

Конфиг CMS, идея реаллизации, хочу узнать мнения

Занимаю сейчас глобальной оптимизацией своей CMS, в том числе оптимизирую, убираю лишние запросы к БД.
Появилась такая идея...
У меня есть таблица config в БД, в которой храняться все настройки CMS меняются они тока из админки и крайне редко.
Вытаскиваются в самом начале одним запросом.
Также есть файл config.php который инклюдится первым, в нем тупо настроки БД: хост, имя базы, юзер, пароль.
Так вот я подумал может есть смысл вытащить из таблицы config все настройки и дописать их в конец config.php, а потом просто если меняешь а админке чтонить заново генерить этот config.php и все...
Так не придется каждый раз брать настройки из БД.

Бред или все же не бред? Интересно Ваше мнение.

 

[Апокалипсис]

А какая проблема? проведи тесты - что будет быстрее.
А если настроек куча - то сделай им кэш конечно.

 

[Nelius]

Ну не то чтобы куча, около ста строк в таблице на данный момент...
Просто еще вопрос в том что у меня настроки в прошлой реализации хранились в глобальном массиве $config. То есть проблем закешировать их не было вообще. А сейчас я твердо решил что завяжу с глобальными переменными и создал класс.
Как кешировать их при этом пока не придумал...

-~{}~ 10.11.07 23:57:

приходит в голову только хранить в ввиде:

$cfg = new config;
$cfg->clear();
$cfg->set('engine_enabled',1);
$cfg->set('engine_auth_salt','Salt!');
...

 

[fixxxer]

гораздо быстрее будет один $cfg->set(array( ... ));

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

 

[DioNiR]

Я впринципе делаю в своей CMS так же как и Nelius.

Знаю что инклуд быстрей чем запрос в БД.
Но возмём к примеру то что надо редактировать некоторые части.
Вот тута уже будет быстрей обновить 1 сроку в БД чем в файле.
Ладно.

Возмём к примеру Статическую Инфу которая у меня в CMS модули, плагины.

Я ж не знаю каков может быть модуль и какие у него конфигурации.
Значит эти данные снова проще занести в БД и с ними работать.

Тута вообще больше дело вкуса и удобства.

 

[Апокалипсис]

Я обычно храню всё в php файле вида
<?
$vars = array();
$vars['param'] = 1;
?>
Зачем дёргать БД лишний раз

 

[Nelius]

DioNiR Ну я файл то парсить не собираюсь) Новое значение в конфиг будет добавлено сначала в БД потом кэш-файл конфига будет просто тупо заново сгенерирован.
По поводу конфигов модулей они в большинстве своем храняться в юзерских конфигах ибо каждый юзер может для себя настроить эти модули... в общем конфиге только дефолтные значения.

-~{}~ 11.11.07 01:13:

Апокалипсис
Хранение конфига в БД для меня лично имеет свои приемущества, например у меня есть столбец fieldtype на основании которого у меня в админке, при редактировании конфига, пхп помещает текущее значение в textarea или в input или еще куда... колонка group определяет группу данного значения и на основании этого у меня реализованны вкладки в этом разделе админки: Конфиг сайта, Конфиг ACP, Конфиг модулей...

А если просто файл без БД то работать с ним как-то геморней...

 

[Апокалипсис]

Не спорю - удобно если параметров куча и они разделены по группам

 

[DioNiR]

Лично для меня удобнее было бы использовать БД.
Если учесть то что моё ядро системы всего использует 4 запроса в БД включая и саму таблицу конфигов. то думаю нагрузки особой я не сделаю.
Понимаю если будет куча запросов то тута хочешь не хочешь надо сокрощать запросы.

Другое дело Модули иммено они жрут запросы и скорость загрузки.
Настройки Модулей и Плагинов я так же храню в этой же самой таблице т.к эти настройки тоже являются конфигурацией.

Да я не заморачиваюсь как Nelius т.е тот же самый fieldtype мне это не нужно так как Админка Статична и я знаю что site_name будет название сайта и ничего больше зачем мне проверять его параметр?
Тот же пример и с динамикой модулей у них тоже конфигурация статична зачем мне проверять что это за параметр если я знаю его или Создатель модуля знает свой параметр?

 

[Духовность™]

Интересно Ваше мнение.

1. Если данные, что лежат в таблице, не редактируются напрямую из админки, то безусловно их нужно вытащить в массив.

2. Любые данные конфигурации, которые может понадобиться изменить во время работы с системой без участия программиста, нужно хранить в БД + иметь интерфейс для их редактирования.

Т.е. пароли к СУБД или пути к директориям нужно зашить в скрипт. Настройки, типа "максимально-допустимая величина пользовательского сообщения", "количество записей на странице" и т.д - нужно хранить в СУБД с возможностью редактирования.

 

[Nelius]

triumvirat
Данные редактируются из админки, но как я писал, крайне редко. Храню в БД имею интерфейс для их редактирования.
Но я предложил вариант как сохранить этот функционал, и при этом не мучать постоянно БД.
То что я хотел знать это ваше мнение по поводу метода кеширования, если вкратце: дописать основной конфиг из БД в файл config.php он итак инклюдится, так что лишнего инклюда не будет + на 1 запрос к БД меньше... а если еще потом закешировать так вообще сказка)
Вот я и спрашивал так ли все радужно как я себе представил или есть подводные камни?)

-~{}~ 11.11.07 04:10:

Автор оригинала: DioNiR
Да я не заморачиваюсь как Nelius т.е тот же самый fieldtype мне это не нужно так как Админка Статична и я знаю что site_name будет название сайта и ничего больше зачем мне проверять его параметр?
Тот же пример и с динамикой модулей у них тоже конфигурация статична зачем мне проверять что это за параметр если я знаю его или Создатель модуля знает свой параметр?

Моя CMS рассчитана на то что ей будут пользоваться люди абсолютно не знающие как там и что устроенно, вот поетому у меня админка напичкана всякими хелпами и удобностями для простых людей...
Пример для чего я использую fieldtype можно у видеть на скриншотах раздела "Конфиг" моей админки, правда это бета версия так что на текст и оформление не обращайте внимания =)))

Как видно на скриншотах мой скрипт опираясь на fieldtype выводит тот или иной параметр или ввиде селекта с ДА\НЕТ или в виде input или в виде текстового поля(textfield) согласитесь так намного удобней работать с настройками)

-~{}~ 11.11.07 04:16:

И еще хотелось бы сказать всем спасибо за помощь и отклики! А большое спасибо 2: Апокалипсис и fixxxer =)