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

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

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

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

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

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

Ответ 1

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

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

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

Недостатки:

Опирается на подключение к базе данных
Накладные расходы при чтении из базы данных

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

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

Недостатки:

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

Почему новый столбец каждый раз? Почему не только 2 столбца: NAME и VALUE.

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

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

Ответ 4

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

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

Ответ 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 цента.

Ответ 6

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

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