Как сохранить параметры конфигурации для веб-приложения?

Question

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

Так что я подумал, может быть, я мог бы сделать таблицу в моей базе данных с именем «meta» и вставить туда значения (или кортежи)!Затем, если модуль был выключен, скрипт обновил бы строку и установил «модуль x» на 0, и я бы покончил с этим, верно?

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

Краткий взгляд на базу данных drupalничего не дал, и я предполагаю, что они используют файл конфигурации на самом сервере?Если это так, я не знаю точно, как сохраненные значения в файле .cfg (например) могут быть прочитаны веб-приложением, и я не знаю, как такое приложение может сохранять информацию в файл.Буду признателен за ваше понимание, если вы решали эту проблему раньше.

Кстати, я использую в основном PHP.

Заранее спасибо!

Answer 1

Я знаю, что ваш вопрос «как я могу читать / писать в отдельный файл на сервере из веб-приложения», но я решил, что я рассмотрю одно из сделанных вами предположений. Нет ничего плохого в сохранении вашей конфигурации в БД.

Я видел проекты (с большим трафиком и хорошим временем безотказной работы - и кучей ИТ-ресурсов, поддерживающих его таким образом = P), которые хранили конфигурацию в базе данных, более или менее, как вы описали. Если это отдельная таблица, и у вас нет сумасшедшей схемы переключения / разделения при сбое, то это не так уж и много.

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

Edit: Тем не менее, если вы получите доступ к этой конфигурации на каждой странице, вы можете столкнуться с узким местом :) Все о вашем дизайне. Одним из решений является то, что если у вас есть постоянный веб-сервис, вы можете повторять его проверку каждые X секунд.

Answer 2

Я часто видел, как это выполнялось с помощью массива конфигурации:

$config["admin_email"] = "admin@mydomain.com";
$config["site_name"] = "Bob's Trinket Store";
$config["excluded_modules"] = array("inventory", "user_chat");

Затем позже вы можете проверить:

if (!in_array("inventory", $config["excluded_modules"])) {
  // include inventory logic
}

Конечно, это немного задом наперед.В действительности было бы разумнее явно объявить включенные модули, а не отрицательные.Затем вы должны ссылаться на это config.php в своем проекте для загрузки и действовать в ответ на различные конфигурации.

Вы также можете реализовать это как таблицу базы данных, сделав по крайней мере два поля:

1. Опция
2. Значение

Где option может быть «exclude_modules», а соответствующее value будет «инвентаризация, user_cat».Хотя, честно говоря, этот метод немного небрежный и может вызвать у вас некоторое разочарование в будущем.

Answer 3

Я предпочитаю работать с ini-файлами в качестве конфигурации, которая находится перед папкой public_html. Я думаю, что это дает мне большую гибкость и группирует var и создает при необходимости отдельные ini для модулей и т. Д.

Answer 4

В принципе, у вас есть два варианта - либо поместить его в таблицу БД, либо в плоский конфигурационный файл (возможно, PHP, возможно, XML). С последним, чтобы сделать его редактируемым со страницы, вам придется (1) справляться с беспорядочными проблемами доступа к файлам в ОС, (1) применять надлежащие права доступа к файлам каждый раз при настройке сайта и (3) анализировать генерировать код PHP / XML. С базой данных все, что вам нужно, это простой запрос, поэтому я бы определенно согласился.

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