лучше хранить конфигурацию платформы в базе данных или файле?

Question

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

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

в моих предыдущих проектах я привык хранить такую ​​информацию в файле.

что лучше / быстрее подходит?

ps, я почти уверен, что кто-то уже имел такой вопрос, но я не могу его найти

Answer 1

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

CREATE TABLE Configuration.GlobalSettings
(
    SectionName VARCHAR(50),
    SettingName VARCHAR(50),
    SettingValue VARCHAR(1000),
    SettingType TINYINT
);

SectionName & SettingName являются первичными ключами, мы просто их разбиваем, чтобы упростить запрос содержимого раздела и разрешить загрузку отдельных разделов в обработчики, а не загружать весь лот в один раз. SettingValue - это строка, а затем SettingType - дискриминатор, который говорит нам, как следует интерпретировать значение параметра (например, 1 = строка, 2 = bool, 3 = десятичная дробь и т. Д.).

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

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

Answer 2

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

Моя жизнь была бы на 10% проще при реализации системного ландшафта, если бы дизайнеры просто сохранили свойства системы в БД.

Answer 3

Это действительно зависит от вашего приложения.

Хранение настроек в базе данных имеет несколько преимуществ:

1. Безопасность - пользователи могут легко изменять настройки в файле или перезаписывать содержимое.
2. Для распространения - одни и те же настройки можно обновлять и загружать на любые машины в сети.

Недостатки:

1. Полагается на соединение с базой данных
2. накладные расходы при чтении из базы данных

Сохранение в файле преимуществ:

1. Быстро и легко читается и изменяется.

Недостатки:

1. Проблема безопасности, как указано выше.
2. Может потребоваться шифрование конфиденциальных данных.
3. Управление версиями затруднено, поскольку вам нужно создавать отдельные файлы для разных версий.

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

но в конце концов, вы должны решить сами, нет лучше или хуже для всех.

Answer 4

Почему каждый раз новый столбец? Почему бы не просто 2 столбца: ИМЯ и ЗНАЧЕНИЕ.

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

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

Answer 5

Если честно, ответ не такой резкий и ясный.

Ответы выше, похоже, не учитывают приложения, которые необходимо развернуть в разных средах, например: dev, qa, staging, prod.

Они также не принимают во внимание важность настройки версий, то есть знания, кто что изменил, где и когда.

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

Каждая среда имеет свою собственную конфигурацию, рассмотрим способ, которым Symfony выкладывает свои файлы конфигурации:

your-project/
├─ app/
│  ├─ ...
│  └─ config/
│     ├─ config.yml
│     ├─ config_dev.yml
│     ├─ config_prod.yml
│     ├─ config_test.yml
│     ├─ parameters.yml
│     ├─ parameters.yml.dist
│     ├─ routing.yml
│     ├─ routing_dev.yml
│     └─ security.yml
├─ ...

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

Мои 2 цента.

Answer 6

Я думаю, что, как все говорили, зависит от среды вашего приложения и требований. Но если бы мне пришлось выбрать общее правило, я бы сказал ОБА. Сначала вы создаете таблицу базы данных для хранения всех ваших конфигураций. Это хорошо по двум причинам: 1) Управление версиями - позволяет легко отслеживать предыдущие конфигурации. 2) Управление - вы можете создать интерфейс, к которому ваши пользователи смогут обращаться для изменения настроек.

Во-вторых, вы создаете файл, который после того, как вы сохранили и опубликовали сайт в рабочей среде, также сохранит все эти настройки в файле, к которому будет легко получить доступ. На самом деле, если вы программируете на PHP для Интернета, этот файл должен быть php-файлом с данными массива (пары ключ-значение), которые не требуют дальнейших манипуляций. Под этим я подразумеваю, что нет необходимости конвертировать ваш yaml или json в массив, если это конечный результат, который вам нужен.