Лучший способ сохранить настройки PHP-приложения?

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

Вещи для хранения как...

  • Глобальное имя веб-сайта.
  • Тема (только переменная или путь к теме)
  • и т.д.

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

UPDATE: Да, файл .ini или синтаксический анализ файла include будет приятным, и я знаю, как это сделать. Но я хотел знать, что было бы лучшим подходом к их хранению в MySQL со всем остальным.

UPDATE2: Причина, по которой я спрашиваю об этом, также заключается в том, что я планирую, что многие из этих параметров могут изменяться через интерфейс администратора. Поэтому, если бы вы изменили название сайта, он сразу же будет обновлен, что, по моему мнению, лучше всего будет делать через SQL, поэтому вам нужно будет установить внутри БД.

ОТВЕТЫ

Ответ 1

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

Поскольку вы будете использовать их повторно в своем PHP-приложении, это будет наиболее идеальным. Это также позволяет избежать необходимости делать вызовы базы данных, если вы должны хранить их в базе данных.

AppSettings.php

<?php
$_SITENAME_ = 'MyWebsite';
$_THEME_ = 'Theme/Path';
?>

UPDATE:

Я предполагаю, что вы хотите, чтобы эти параметры были доступны для редактирования через веб-страницу и не нуждались в нескольких запросах БД, поскольку эти параметры будут меняться, но не слишком часто?

Один из подходов, который я лично принял, - это сериализовать таблицу AppSettings и сохранить ее в файле XML. Конечно, каждый раз, когда таблица обновляется, таблица будет ресериализована и сохранена в XML файле. Затем я создал отдельный класс, который анализирует XML файл и возвращает нужные мне значения.

Ответ 2

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

Для сайтов с высоким трафиком с большими конфигурациями кэширование ваших конфигурационных данных в APC (например, как один массив) является хорошей идеей - по крайней мере, вы сохраняете накладные расходы на выполнение операторов в вашем config.php файл. Примечательно, что facebook делает это. Когда вы подаете много запросов в секунду, попадание диска на чтение файла конфигурации (с использованием parse_ini_file, анализатора XML и т.д.) Для каждого запроса не может быть и речи.

Для моего текущего проекта у нас есть много сайтов, каждый со своей собственной конфигурацией. На каждом сайте были и база данных, и файл конфигурации; однако, убедитесь, что вы всегда используете правильный файл конфигурации с правильной базой данных, которая может стать головной болью. Кроме того, изменения потребуют изменения вещей в двух местах - db и config. Забывание того или другого всегда вызывало проблемы, и это случалось слишком часто.

Мы переместили конфигурацию в базу данных, чтобы вы не могли отделить db от правильной конфигурации, и для любых изменений кода требуется только обновление базы данных. Данные из таблицы config также агрессивно кэшируются в APC, поэтому мы запрашиваем его редко.

Итак, чтобы повторить:

  • Малый сайт: просто используйте файл config.php
  • Очень большой сайт: кеш в APC
  • Несколько сайтов: сохранить конфигурацию в базе данных, чтобы уменьшить административные издержки; кеш в APC для уменьшения попадания в базу данных.

Ответ 3

Мы просто используем

$siteConfig['db_name'] = 'database1';
$siteConfig['site_name'] = 'Stackoverflow';

В включенном файле php. Ввод значений в массив помогает с конфликтами имен.

Ответ 4

Я понимаю, что вы хотите хранить вещи в таблице mysql, однако это, вероятно, означает сохранение требуемой конфигурации в нескольких местах. например, я уверен, что вам понадобится сервер базы данных и имя, хранящиеся в какой-либо строке. это означает, что они помещаются в файл include или .ini, поскольку вы не можете их прочитать из базы данных (как вы можете подключиться к базе данных, не зная об этом). так что вы будете хранить информацию о подключении db в файле include или .ini и остальных настройках базы данных? это работает, я полагаю, но мне нравится сохранять все настройки в одном файле (config.php или application.ini или что-то еще). это упрощает обслуживание imo.

-don

Ответ 5

Просто общался с несколькими людьми в IRC об этом. Я посмотрел, как Wordpress справился с этим после того, как я вытащил SQL-дамп одной копии. Я думаю, что я буду использовать этот макет и немного переименовать столбцы. Но идея...

option_id | option_name | option_value | autoload
int       | varchar     | longtext     | varchar
(PRIMARY) | (UNIQUE)    |              |

Ответ 6

Как правило, в моем файле 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 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));
?>

Ответ 7

Достойный подход состоял бы в том, чтобы извлекать часто используемые настройки один раз на страницу через базу данных. Что-то вроде сохранения поля bool autoload, которое проверяет, должен ли параметр загружаться со страницей. Для других, гораздо менее привычных настроек вы можете получить их по воздуху.

Если вы решили кэшировать их все вместо того, чтобы извлекать данные для каждой страницы, вам может понадобиться сообщить об уведомлении script о перезагрузке настроек - или вам придется вручную сообщить об этом, поэтому вы не застряли со старыми настройками после изменения некоторых.