Информация о конфигурации приложения: MySQL, XML или PHP Class?
Я занимаюсь разработкой приложения PHP / MySQL. Сейчас я записываю набор данных, которые будут служить информацией о конфигурации приложения. По сути, они не будут изменены, точка.
Я нахожусь в поиске наилучшей практики хранения таких данных, но пока нет четкого ответа.
Я знаю, что для этой цели популярно использовать XML, но вам нужно разобрать его в отдельном вызове функции, и файлы будут читать медленнее.
Я думал о написании PHP-класса, который будет включен в конфигурацию, чтобы при каждом запуске приложения оно загружалось, что-то вроде переменных среды. Но это все еще хорошее решение, если у меня их всего несколько, или их довольно много?
Я знаю, что выполняю запросы MySQL для большинства моих вызовов API. Однако является ли MySQL отличным выбором, если данные только читаются?
P.S — если быть более точным, структура данных конфигурации похожа на:
"Products": [
"1": "Apple",
"2": "Orange",
"4": "Pear"]
Я храню ключи в базе данных («1», «2» или «4»), а затем представляю их в своем пользовательском интерфейсе с английскими словами. Я правильно делаю со структурой данных?
В настоящее время это выглядит как очень простые и маленькие данные. Но я ожидаю, что он вырастет до сотен подобных данных.
Решение
Постарайтесь сохранить все ваши данные конфигурации внутри основных массивов PHP и включите файл (ы) в начало вашего приложения.
# Your main application
$conf = include 'conf.php';
С conf.php возвращая массив PHP:
return array(
'key1' => 'value1',
);
Вы также можете разбить конфигурацию на несколько файлов, чтобы упростить процесс разработки и тестирования приложения. Например, вы можете создать conf/shared.php со всеми общими параметрами конфигурации. Второй файл conf/dev.php будет содержать все параметры конфигурации, которые вам понадобятся во время работы приложения на компьютере разработчика (например, параметры подключения к базе данных, параметры журнала и т. д.). Третий файл conf/prod.php будет содержать все, что необходимо, пока приложение работает в производственной среде.
# Your main application
$conf = include 'conf/shared.php';
# Determine the application environment
# Note: You will need to set the environment variable inside the Apache configuration for yourself
if (!isset($_ENV['appEnv'])) {
# Make sure the environment is always set
$_ENV['appEnv'] = 'dev';
}
# Include the needed environment config file and merge it with shared
$conf = array_merge_recursive($conf, include 'conf/' . $_ENV['appEnv'] . '.php');
Если бы я был вами, я бы не думал о кэшировании конфигурации на данном этапе разработки вашего приложения. Старайтесь писать только то, что вам нужно в данный момент, но пишите их ясно и без ошибок … Всегда возможно реализовать какое-либо кэширование конфигурации позже, когда вам это действительно понадобится. IMO, если вы придерживаетесь основных массивов PHP, это не нужно делать, если вам не нужно включать много файлов или действительно большие массивы (более 1000 записей).
Другие решения
ИМХО Конфигурация приложения должна быть прочитана как можно быстрее, потому что она должна читаться при каждом запросе.
Лучший способ добиться этого — использовать простой массив PHP. Нет более быстрого решения, чем простой PHP-массив в сочетании с кэшем кода операции (например, APC или Opcache).
Но это не значит, что вы должны написать эту конфигурацию как обычный массив PHP. Вы должны использовать то, что вам удобнее всего. XML, YAML, JSON и т. Д. На самом деле не имеют значения.
Идея состоит в том, что конфигурация считывается из файла в вашем любимом формате, преобразуется в простой массив PHP, а затем сохраняется как PHP в другом файле, только в первый раз. В следующий раз, когда потребуется конфигурация, обычный массив PHP должен быть прочитан из файла. Другими словами: только если простая версия PHP недоступна, вы читаете другой формат и создаете его.
Я рекомендую взглянуть на Компонент Symfony 2 Config, что облегчает этот процесс.
Если вы храните его в базе данных, где находятся настройки подключения к вашей базе данных?
С файлами конфигурации гораздо проще работать, их можно поместить в вашу систему контроля версий, чтобы увидеть изменения во времени и т. Д.
Я обычно пытаюсь использовать функцию parse_ini_file
чтобы сохранить его в хорошо известном формате, и дать понять, что это не код его конфигурации.
XML немного сложнее, так как вы также должны получить правильный синтаксис, хотя и предлагает некоторую большую гибкость. Поэтому я считаю, что использовать XML можно только тогда, когда у вас есть параметры, которые вы не можете представить в INI-файле
Разделы ini отлично подходят для разделения live, staging и dev config, а также для разделения их, но вместе в простой и удобной для редактирования форме.
Лично я люблю (и нахожу их действительно мощную) конфигурацию PHP-файлов, но для крупномасштабного приложения я бы предпочел хранить код и конфигурацию в отдельных областях. Я люблю json и нахожу его действительно простым для понимания, и PHP может декодировать его с помощью встроенной функции json_decode (). Итак, IMHO JSON — лучший способ создать большой файл конфигурации.
Массив, хранящийся непосредственно в PHP, будет для этого самым простым способом. Сотни, тысячи строк, нет проблем. За тысячу, я бы порекомендовал положить в базу данных
Вы упомянули, что видите, что набор данных растет. Важными вопросами для рассмотрения являются: как вы будете управлять этим ростом, будете ли вы изменять данные вручную или генерировать их. Вы видите, используя другой язык позже. JSON очень популярен и есть эффективные парсеры.
Надеюсь, это поможет.