Brabus2008 а какого типа параметры вы хотите хранит как конфигурационные?

krundetz, всяческие параметры системы, статус какого-либо функционала (вкл/выкл), адреса директорий и пр. В общем строки.
Самое глупое то, что изначально я в курсе, что брать эти параметры быстрее с файла, по сраневнию с запросом к бд. (будем иметь вду, что файл и сервер бд на локалхосте, выборка без всяких сортировок и группирований). Но разница между ними мизерная, если сравнивать "по одному". А когда в цикле 1000 одинаковых запросов туда и туда, файлы выигрывают почти вдвое. Но меня интересует ОДНОВРЕМЕННЫЕ обращения, которые я смоделировать точно не могу  На самом деле логично и далее предположить, что к файлам быстрее... Но насколько эти значения будут расходится и стоит ли идти у них на поводу.

Это сообщение отредактировал(а) Brabus2008 - 1.6.2008, 20:27

правильно.

правильно.

Однако ни один веб-сайт не отказывается от использования БД.
Теперь осталось сложить два и два, и сделать таки вывод, о котором я говорил с самого начала - видимо, скорость, быстродействие и производительность - не единственные факторы, по которым выбирается та или иная технология.
Вот пример: мы хотим хранить данные в БД. А зачем? Это реляционная информация? Мы будем сортировать эти данные? Связывать с ними какие-то другие? Запрашивать по отдельности? Если нет - то зачем нам БД вообще? Зачем использовать инструмент не по назначению? Почему такой очевидный критерий не рассматривается? 
Ну ладно - храним в БД. А как? Это будет эмуляция файла (все одним куском) или по строке на параметр? 
Этот вопрос интересен, поскольку тесно связан с вопросом "удобства", которое сводится, как я думаю, к количеству кода. 
$config=unserialize($file_get_contents(conf.txt)); - это неудобно?
Если в БД одним куском, то какая разница с 
$config=db->get_one(unserialize($file_get_contents(conf.txt));
?

Ну, в данный момент я повсеместно использую хранение в файле ini. Брать легко: parse_ini_file . А вот с записью мне не очень нравится. Нужно вышеуказанной функцией пропарсить файл, найти в массиве нужное значение, изменить его, и опять массив записать в нужном формате в файл. Куда удобней обновить одну запись в бд. Грубо говоря, во мне борятся два мнения: удобство (бд) или скорость (файл) 

Где э тут неудобство, если у тебя код уже написан?
И в том, и в другом случае все сводится к вызову одной функции. 

Удобство БД не в способе записи в неё данных, а в легкости манипулирования ими!

к сказанному Feldmarschall, хочу добавить ещё одно замечание. архитектурное.
обычно, все настройки настройки системы представляют собой многомерный массив(дерево или даже граф - в зависимости от ситуции): как минимум, "разделы" конфигурации(подключение к БД, язык интерфейса, режим работы.... да мало ли ещё!) и собственно параметры конфигурации(имя пользователя БД, имя каталога с картинками, и т.д. и т.п.), а БД у нас в основном используются реляционные. И получается, что для формаирования набора настроек из двумерного массива, хранящегося в БД, приходится делать дополнительную обработку. В то время, как при хранении в PHP-файле в виде массива достаточно просто сделать include. Да, с точки зрения скорости выполнения разницы большой не будет(один запрос к БД или одноразовая обработка включаемого скрипта), но в случае с файлом всю "грязную" работу делает PHP. Так зачем усложнять код и открывать дополнительный простор для совершения ошибок?  

Мм, верное замечание, спасибо.

как вам это по удобству.

Я что то не понимаю вас. Конфигурация это то что у нас должно подгрузиться в любом случае. В не зависимости от того чего это конфигурация всей системы или отдельного модуля. Какя здесь может быть вообще выборка. Пример. Есть система парсинга. Конфигурация в этом случае это адрес ресурса с которого парсим и адрес файла в с правилами парсинга. Все и то и другое необходимо. Если у нас есть какаята выборка по параметрам то это уже не конфигурация, а логика. Данные с которыми работает логика лучше хранить в БД.

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

ну, у тебя же картинки отдельно друг от друга лежат, так?   
да и модули - не все в одном-единственном файле...
вот когда однородная/однотипная информация начинает дробиться(на разные таблицы с одинаковой структурой... или на разные файлы) без веской причины, то это "не централизовано". а если информация разнотипная, ещё и по возможности - друг от друга не зависящая, то наоборот разделение - лучше. потому что делает части минимально зависящими друг от друга.

Добавлено через 1 минуту и 8 секунд
но это, опять же, разговор о "сферическом коне в вакууме", потому что все зависит от условий конкретной задачи: модели, ограничений на реализацию, требования к функционалу... в "общем виде" универсального решения нет.

Brabus2008 ИМХО странный както вы пример привели. Причем здесь админка? Скорость исполнения скриптов в админке не имеет существенного значения там важно совершенно другое(не будете же вы их менять каждую минуту). Да и скорость с которой будйт меняться конфигурационные параметры будет по определению больше чем скорость их чтения и не важно что это увас будет файл или БД.

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

Это сообщение отредактировал(а) krundetz - 1.6.2008, 22:39

Как я уже сказал в своём вопросе http://forum.vingrad.ru/forum/topic-216786...y1550927/0.html , я сохраняю данные в xml-файле и вношу запись о нём в MySQL-базу.
Но это - для общего решения о сохранении заранее неизвестного количества неоднородных переменных некоего скрипта, одного из очень многих и имеющего такие ассоциативные признаки, как, к примеру, "username того, от чьего имени скрипт запущен", "время предыдущего запуска" и т.п.

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

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

Как вариант: XML.




Кэшируйте.

Файл конфигурации и спец. класс для парсинга и отдачи. Синглтоном.

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

Добавлено через 3 минуты и 18 секунд
И, кстати, вариант типа $config = unserialize(file_get_contents('config.serialized.php')) будет по-быстрее, чем $config = array('blabla' => 'blabla', ......).