Сохранение глобальных настроек сайта [PHP/MySQL]

Это выглядит прекрасно, как вы это делаете.

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

Вот более чистая версия запроса, который вы дали в своем вопросе:

SELECT name, value FROM preferences
WHERE name IN ('picture_sizes','num_picture_fields','server_path_to_http','picture_directory')";

Или, возможно, создайте хранимую функцию для возврата значения предпочтения; например, используя хранимую функцию следующим образом:

DELIMITER $$

CREATE FUNCTION `getPreference` (p_name VARCHAR(50)) RETURNS VARCHAR(200)
BEGIN
  RETURN (SELECT `value` FROM preferences WHERE `name` = p_name);
END $$

DELIMITER ;

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

SELECT getPreference('server_path_to_http')

Вы немного жертвуете скоростью, не запрограммировав свои предпочтения (очевидно). Но если вы планируете разрешить «администратору сайта» изменять настройки по умолчанию, вам следует сохранить их в базе данных.

В моем приложении я использую эту структуру:

CREATE TABLE `general_settings` (
  `setting_key` varchar(255) NOT NULL,
  `setting_group` varchar(255) NOT NULL DEFAULT 'general',
  `setting_label` varchar(255) DEFAULT NULL,
  `setting_type` enum('text','integer','float','textarea','select','radio','checkbox') NOT NULL DEFAULT 'text',
  `setting_value` text NOT NULL,
  `setting_options` varchar(255) DEFAULT NULL,
  `setting_weight` int(11) DEFAULT '0',
  PRIMARY KEY (`setting_key`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Пример данных:

mysql> select * from general_settings;
+-----------------------------+---------------+------------------------------+--------------+-------------------------------+---------------------------------------+----------------+
| setting_key                 | setting_group | setting_label                | setting_type | setting_value                 | setting_options                       | setting_weight |
+-----------------------------+---------------+------------------------------+--------------+-------------------------------+---------------------------------------+----------------+
| website_name                | website       | Website Name                 | text         | s:6:"DeenTV";                 | NULL                                  |              1 | 

Я храню сериализованное значение в столбце setting_value. Я получил этот трюк от wordpress, чтобы сохранить настройки в базе данных.

Столбец setting_options используется для select, radio или checkbox setting_type. Он будет содержать сериализованное значение массива. В админке это значение будет отображаться как опция, так что админ может выбрать одну из них.

Поскольку я использую CodeIgniter, у меня есть модель для получения одного значения из конкретного setting_key, поэтому ее довольно легко использовать.

Я думаю, что это вполне приемлемая структура, особенно для небольшого количества конфигураций, как у вас.

Вы также можете сохранить эти настройки в файле .ini и вызвать parse_ini_file. Если вам нужно немного больше гибкости, чем позволяет INI (например, вложенные массивы и т. д.), вы можете просто поместить их все в файл .php и включить его.

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

$config = array();
$result = mysql_query("SELECT * FROM config");
while ($row = mysql_fetch_assoc($result)) {
    $config[$row['name']] = $row['value'];
}

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

Множество приложений, в т.ч. Wordpress, используйте сериализацию и десериализацию. Это позволяет вам создать очень простую структуру таблицы, возможно, даже с одной записью (например, с site_id для вашего проекта (ов)).

Все ваши (многие, многие) переменные в массиве сериализуются в строку и сохраняются. Затем извлекается и несериализуется обратно в структуру вашего массива.

Pro: вам не нужно заранее планировать идеальные структуры конфигурации, выполняя множество операций ALTER TABLE.

Минусы: вы не можете выполнять поиск в сериализованной структуре массива с помощью SQL.

Команды:

string serialize  ( mixed $value  )
mixed unserialize  ( string $str  )

Работает также с вашими объектами. Для десериализации объекта можно использовать метод __wakeup().

Просто создайте класс configure и сохраните каждое значение, которое вы хотите, в переменной класса.

включить этот класс во все файлы, которые вызывает.

Теперь вы можете получить доступ к этому классу во всех файлах, и, объявив глобальную функцию во всех, вы можете получить доступ к классу конфигурации.

Надеюсь, это поможет.

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

CREATE TABLE IF NOT EXISTS `global_config` (
  `row_limiter` enum('onlyOneRowAllowed') NOT NULL DEFAULT 'onlyOneRowAllowed',#only one possible value
  `someconfigvar` int(10) UNSIGNED NOT NULL DEFAULT 0,
  `someotherconfigvar` varchar(32) DEFAULT 'whatever',
  PRIMARY KEY(`row_limiter`)#primary key on a field which only allows one possible value
) ENGINE = InnoDB;

INSERT IGNORE INTO `global_config` () VALUES ();#to ensure our one row exists

После того, как вы выполнили эту настройку, любое из значений может быть изменено с помощью простого оператора UPDATE, найдено с помощью простого оператора SELECT, объединено с другими таблицами для использования в более сложных запросах и т. д.

Еще одно преимущество этого подхода заключается в том, что он позволяет использовать надлежащие типы данных, внешние ключи и все остальное, что необходимо при правильном проектировании базы данных для обеспечения целостности базы данных. (Просто убедитесь, что ваши внешние ключи ON DELETE SET NULL или ON DELETE RESTRICT, а не ON DELETE CASCADE). Например, предположим, что одна из ваших переменных конфигурации является идентификатором пользователя основного администратора сайта, вы можете расширить пример следующим образом:

CREATE TABLE IF NOT EXISTS `global_config` (
  `row_limiter` enum('onlyOneRowAllowed') NOT NULL DEFAULT 'onlyOneRowAllowed',
  `someconfigvar` int(10) UNSIGNED NOT NULL DEFAULT 0,
  `someotherconfigvar` varchar(32) DEFAULT 'whatever',
  `primary_admin_id` bigint(20) UNSIGNED NOT NULL,
  PRIMARY KEY(`row_limiter`),
  FOREIGN KEY(`primary_admin_id`) REFERENCES `users`(`user_id`) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE = InnoDB;

INSERT IGNORE INTO `global_config` (`primary_admin_id`) VALUES (1);#assuming your DB is set up that the initial user created is also the admin

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