Каков наилучший способ хранения группы глобальных параметров для пользовательского PHP-приложения? Я работаю над личным проектом (на первый взгляд, действительно), и мне нужен метод хранения пар ключ-значение для записи общих настроек для приложения.
Вещи для хранения как …
Должен ли я просто держать их в одном столе? Если да, то каков наилучший способ запросить их у бункера? Помимо выполнения одного запроса для каждой желаемой настройки.
UPDATE: Да. A .ini или разбор включенного файла будет приятным, и я знаю, как это сделать. Но я хотел знать, какой будет лучший подход к их хранению в MySQL со всем остальным.
UPDATE2: Причина, по которой я спрашиваю об этом, также заключается в том, что я планирую, что многие из этих параметров могут изменяться через интерфейс администратора. Поэтому, если вы изменили название сайта, он будет обновлен сразу, и я решил, что лучше всего будет делать это через SQL, поэтому вам нужно будет установить внутри БД.
Вы думали о том, чтобы поместить их в файл .php и включить его на страницы, которые вам нужно использовать? Дайте переменным уникальное имя, чтобы избежать конфликтов имен.
Поскольку вы будете использовать их повторно в своем приложении PHP, это будет наиболее идеальным. Это также позволяет избежать необходимости делать вызовы базы данных, если вы должны хранить их в базе данных.
AppSettings.php
<?php $_SITENAME_ = 'MyWebsite'; $_THEME_ = 'Theme/Path'; ?>
Я предполагаю, что вы хотите, чтобы эти параметры были доступны для редактирования через веб-страницу и не нуждались в нескольких запросах БД, поскольку эти параметры будут меняться, но не слишком часто?
Один из подходов, который я лично принял, – это сериализовать таблицу AppSettings и сохранить ее в XML файле. Конечно, каждый раз, когда таблица обновляется, таблица будет ресериализована и сохранена в XML-файле. Затем я создал отдельный класс, который анализирует XML-файл и возвращает нужные мне значения.
Для одного, небольшого, простого сайта я просто установил конфигурацию в файл PHP. Будь проще. PHP, вероятно, не разбирает ничего быстрее, чем анализирует PHP. Если вы используете APC, скомпилированный байт-код даже кэшируется – хотя байт-код затем повторно выполняется для каждого запроса. Для небольшого файла конфигурации это выполнение байт-кода должно занимать очень мало времени; для очень большого файла это может занять немного больше времени.
Для сайтов с высоким трафиком с большими конфигурациями рекомендуется кэшировать ваши данные конфигурации в APC (например, в виде единого массива) – по крайней мере, вы сохраняете накладные расходы на выполнение операторов в файле config.php. Примечательно, что facebook делает это. Когда вы подаете много запросов в секунду, при каждом нажатии запроса на чтение файла конфигурации (с использованием parse_ini_file, анализатора XML и т. Д.) На каждый запрос не может быть и речи.
Для моего текущего проекта у нас есть много сайтов, каждый со своей собственной конфигурацией. На каждом сайте были и база данных, и файл конфигурации; однако, убедитесь, что вы всегда используете правильный файл конфигурации с правильной базой данных, которая может стать головной болью. Кроме того, изменения потребуют изменения вещей в двух местах – db и config. Забывание того или другого всегда вызывало проблемы, и это случалось слишком часто.
Мы переместили конфигурацию в базу данных, так что вы не можете отделить db от правильной конфигурации, и для любых изменений кода требуется только обновление базы данных. Данные из таблицы config также агрессивно кэшируются в APC, поэтому мы запрашиваем его редко.
Итак, напомню:
Мы просто используем
$siteConfig['db_name'] = 'database1'; $siteConfig['site_name'] = 'Stackoverflow';
В включенном файле php. Ввод значений в массив помогает с конфликтами имен.
Я понимаю, что вы хотите хранить вещи в таблице mysql, однако это, вероятно, означает сохранение требуемой конфигурации в нескольких местах. например, я уверен, что вам понадобится сервер базы данных и имя, хранящиеся в какой-либо строке. это означает, что они помещаются в файл include или .ini, поскольку вы не можете их прочитать из базы данных (как вы можете подключиться к базе данных, не зная об этом). так что вы будете хранить информацию о подключении db в файле include или .ini и остальных настройках базы данных? это работает, я полагаю, но мне нравится сохранять все настройки в одном файле (config.php или application.ini или что-то еще). это упрощает обслуживание imo.
-дон
Просто об этом поговорили с несколькими людьми в IRC. Я посмотрел, как WordPress справился с этим после того, как я вытащил SQL-дамп одной копии. Я думаю, что я буду использовать этот макет и немного переименовать столбцы. Но идея …
option_id | option_name | option_value | autoload int | varchar | longtext | varchar (PRIMARY) | (UNIQUE) | |
Обычно я в файле index.php настраиваю «необходимые» настройки так:
<?php session_start(); ob_start(); define('BASEPATH', $_SERVER['DOCUMENT_ROOT'].'/_setUp/siteSetup/'); // CHANGE TO THE PATH OF THE SITE. define('URIPATH', 'http://localhost/_setUp/siteSetup/'); // CHANGE TO THE URL OF THE SITE. define ('DEBUGGER', true); // CHANGE TO FALSE TO HIDE DEBUG MESSAGES include(BASEPATH.'system/lib/config.lib.php'); ?>в<?php session_start(); ob_start(); define('BASEPATH', $_SERVER['DOCUMENT_ROOT'].'/_setUp/siteSetup/'); // CHANGE TO THE PATH OF THE SITE. define('URIPATH', 'http://localhost/_setUp/siteSetup/'); // CHANGE TO THE URL OF THE SITE. define ('DEBUGGER', true); // CHANGE TO FALSE TO HIDE DEBUG MESSAGES include(BASEPATH.'system/lib/config.lib.php'); ?>
и в моем файле конфигурации:
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); // public /* example: <img src="<?php echo IMG ?>my_image.jpg"> http://localhost/public/images/ <img src="http://localhost/public/images/my_image.jpg"> */ define('CSS', URIPATH.'public/css/'); // DEFINE DIR: css define('IMG', URIPATH.'public/images/'); // DEFINE DIR: images define('JS', URIPATH.'public/scripts/'); // DEFINE DIR: scripts // system define('INC', BASEPATH.'system/includes/'); // DEFINE DIR: includes define('LIB', BASEPATH.'system/lib/'); // DEFINE DIR: lib define('SQL', BASEPATH.'system/sql/'); // DEFINE DIR: sql if (DEBUGGER) { ini_set('log_errors',TRUE); ini_set("error_log", BASEPATH.'system/'."error_log.txt"); } else { ini_set('log_errors',TRUE); ini_set("error_log", BASEPATH.'system/'."error_log.txt"); } $db_info = array( 'host' => 'localhost', 'username' => 'root', 'password' => 'root', 'database' => 'my_db' ); /* to use: $db_info = unserialize(DB_INFO); echo $db_info['host']; echo $db_info['username']; echo $db_info['password']; echo $db_info['database']; */ define('DB_INFO', serialize($db_info)); ?>
Достойный подход состоял бы в том, чтобы получать обычно используемые настройки один раз на страницу через базу данных. Что-то вроде сохранения поля autoload bool, которое проверяет, должен ли параметр загружаться со страницей. Для других, гораздо менее привычных настроек вы можете получать их по воздуху.
Если вы решите кэшировать их все, а не извлекать для каждой страницы, вы можете подумать о способе уведомления сценария о перезагрузке настроек – или вам придется вручную сообщить об этом, чтобы вы этого не сделали застрял со старыми настройками после изменения некоторых.