где и как хранить/подключать конфиги?

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

где и как хранить/подключать конфиги?

Проектируя систему я столкнулся с ситуацией, когда нужно хранить массу настроек.

Например эти:

$_HTML['params']['marital_status'] = array(
1=>'в браке', 
2=>'холост/не замужем'
);

$_HTML['params']['education'] = array(
1=>'Среднее', 
2=>'Среднее специальное', 
3=>'Неоконченное высшее', 
4=>'Высшее', 
5=>'Степень MBA');

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

Какой выход? Разбивать настройки по модулям и подключать какой нужно? Минус один вижу - количество файлов разрастается, потеряется контроль, труднее будет ориентироваться между ними.

Или таскать это все в памяти? Сейчас уже 600 строк конфигурации на реальных 3 модуля системы )

 

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

в каждом модуле файл config.php, не ?

 

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

Апокалипсис
это сумасойдешь их подключать/редактировать

 

[weregod]

подключать не сойдёте, если каждый модуль единообразен, а редактировать - тогда как есть, в одном файле храните

либо раскидайте конфиги по типам данных чтоли...

 

[iceman]

скачай библитеку организующая Конфиг....

опять же в Zend Framework есть Zend_Config (Zend_Config_Ini (или Zend_Config_Xml) думаю тебе больше подайдет) очень удобный для использования...

 

[maxru]

Я один подумал про базу данных?

 

[Beavis]

triumvirat
а эти "настройки" случайно не дублируются в базе данных в поле enum?

 

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

Я один подумал про базу данных?

наверно. хранение подобных настроек в СУБД ничем не оправданно. только лишние запросы и сложность удаления\добавления новых элементов списка.

Beavis
нет. нет никаких enum

 

[флоппик]

сложность удаления\добавления новых элементов

а?
А потом ты начнешь мультиязычную версию делать, да?
Не экономь на спичках, храни в базе. Сам подумай, что проще — выбрать из базы по необходимости, или таскать это добро в памяти в каждом вызове скрипта?

 

[Kib]

Автор оригинала: triumvirat
наверно. хранение подобных настроек в СУБД ничем не оправданно. только лишние запросы и сложность удаления\добавления новых элементов списка.

а зачем вообще тогда СУБД???, сложности удаления и добавления не вижу, обычная работа с данными.
p.s. если не трудно расскажи почему не оправданно

 

[iceman]

нада разделять конфиг скриптов, от пользовательских...

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

 

[Santiago]

Это больше на справочники похоже, чем на конфиги.
А справочники лучше хранить в БД.

 

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

Не экономь на спичках

это не спички. это просто удобство использования.

какой смысл хранить в базе два статичных поля, "Да"-"Нет", "Муж"-"Жен", писать для них функцию выборки и юзать базу, если можно все это в массив сложить?

 

[флоппик]

какой смысл хранить в базе два статичных поля, "Да"-"Нет", "Муж"-"Жен", писать для них функцию выборки и юзать базу, если можно все это в массив сложить?

что проще — выбрать из базы по необходимости, или таскать это добро в памяти в каждом вызове скрипта?

А потом ты начнешь мультиязычную версию делать

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

echo ($_HTML['params']['marital_status'][$query_result['matrial_status']]);

А храня справочники отдельно от данных, без учета их отношений, ты нарушаешь целостность данных в БД. Ты ведь пользуешься внешними ключами, правда?
Еще один аргумент — как в твою систему, конечному прользователю добавить в справочник варианты (Разведен(Нет детей), Разведен (Есть дети)) — ? Лезть в код? В config.php и еще десять файлов где они у тебя делаются проверки на допустимость, или еще что то?
Нельзя разрушать слой абстракции.

 

[cranchzerro]

http://www.mzz.ru/docs/structure.classes.html#structure.classes.resolver

 

[флоппик]

cranchzerro, вопрос пока стоит не «как эффективней подключить файлы с конфигами», а «надо ли их использовать». И агрументация в данной дискуссии гораздо полезнее ссылок на абстрактный код.

 

[cranchzerro]

ну про Zend_Config (хотя я не имею ввиду именно его) уже написали, это скорее логика структуры организации контекстного конфига, и поэтому я написал только про механизм подключения конкретных конфигов.

а так, вообще, имхо DOM, точнее - обычное дерево

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

короче: XML-конфиг, который сам по себе уже и есть дерево, далее некие сервисы которые знают что нужно каждому плагину, модулю и т.д. то есть Service Locator с другой стороны абстракции. Ну а если конфиги большие (читать как ахринительно большие) то совокупность xml-конфигов, которые этот самый "менеджер" конфигов будет загружать по требованию.

так же, если суммарный размер ваших конфигов действительно большой, что XML-парсинг ну просто непозволителен - пересмотреть архитектуру (ну или действительно - задуматься над использованием БД для... конфигов, ИЛИ не считать "конфигом" всё, что динамически меняется...)

 

[Nelius]

Из приведенного примера видно что при проектировании мультиязычного приложения эти данные должны будут существовать на разных языках.

Не знаю какое у вас приложение но рассмотрю как для мультиязычного.

Мне кажется хранить все в одном файле не оптимально, потому что приходится загружать в память лишние справочники которые могут не использоваться в данном модуле.
Также, возможно будут данные которые используются во всех модулях, их можно выделить в справочник "Основной" или "Общий" и подключать всегда.

Я бы хранил все эти данные как языковые файлы (например в формате gettext или в xml или массивы php), потом загружал бы их в БД разделяя по справочникам. Далее в приложении появляется гибкость, можно один раз взять общие данные для всех модулей, кэшировать и брать данные из справочников которые необходимы в конкретном случае (можно тоже кэшировать).

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

В общем это моя реализация, насколько она хороша я не знаю... если что пинайте.

 

[grigori]

это действительно не "конфигурация", а список вариантов, справочник

судя по описанию, проблема высосана из пальца -
хранить в памяти 600 строк типа "Среднее", "мужской" общим размером 30 кбайт - мелочь
неприятен лишь парсинг этого файла при каждом вызове, но это решается кешем
(для сравнения файл Smarty.class.php - 2000 строк, 63 Кб)

флоппик база удобна далеко не всем, лично мне отредактировать строку в текстовом файле, зайдя на сервер по ssh реально проще, чем менять запись бд
и мультиязычность не рассматривается

 

[weregod]

grigori
> флоппик база удобна далеко не всем, лично мне отредактировать строку в текстовом файле, зайдя на сервер по ssh реально проще, чем менять запись бд
и мультиязычность не рассматривается

Вы рассуждаете с точки зрения разработчика и человека, знакомого с понятием "терминал" и т.д. и т.п.
большенству удобнее для измнения параметров системы (рассмотрим более общий вариант) браузер

так как
> общая сумма разума на планете - величина постоянная, а население растёт
то терминалы давно уже уступают браузерам в популярности, + на лицо тенденция хранения пользовательских данных в БД
посему утверждение "база удобна далеко не всем" стоит рассматривать как утверждение "база удобна далеко не всем из" ))