лучше сохранить конфигурацию платформы в базе данных или файле?
https://docs.python.org/library/os.html
Для дополнения сообщения Greg, если Вы находитесь в posix системе, которая включает MacOS, Linux, Unix, и т.д. можно использовать os.uname () для получения лучшего ощущения того, какая система это.
4 ответа
Это действительно зависит от вашего приложения.
Сохранение настроек в базе данных имеет несколько преимуществ:
- Безопасность - пользователи могут легко изменять настройки в файле или перезаписывать содержимое.
- Для распространения - одни и те же настройки могут быть обновлены и загружены на любые машины в сети.
Недостатки:
- Зависит от соединения с базой данных
- Накладные расходы при чтении из базы данных
Преимущества хранения в файле:
- Быстро и легко читать и изменять.
Недостатки:
- Проблема безопасности, упомянутая выше.
- Может потребоваться шифрование конфиденциальных данных.
- Управление версиями затруднено, поскольку вам нужно создавать отдельные файлы для разных версий.
это означает, что каждый раз, когда мы добавляем настройку платформы, мы должны добавлять столбец в эту таблицу. - в зависимости от того, какую базу данных вы используете, но вы можете сохранить все настройки в виде XML (SQL-сервер позволяет это) в таблице, поэтому вам не нужно изменять схему таблицы каждый раз, добавляя настройки; все, что вам нужно сделать, это изменить XML, добавив в него элементы или удалив из него.
но, в конце концов, вы должны решить сами, нет ничего лучше или хуже для всех.
Мы храним настройки конфигурации в таблице типа ключ / значение, например:
CREATE TABLE Configuration.GlobalSettings
(
SectionName VARCHAR(50),
SettingName VARCHAR(50),
SettingValue VARCHAR(1000),
SettingType TINYINT
);
Имя раздела и Имя параметра - это первичный ключ, мы просто разделите их, чтобы упростить запрос содержимого раздела и разрешить загрузку отдельных разделов в обработчики, а не загружать всю партию сразу. SettingValue - это строка, а затем SettingType - это дискриминатор, который сообщает нам, как следует интерпретировать значение параметра (например, 1 = строка, 2 = логическое значение, 3 = десятичное и т. Д. .).
Это означает, что вам не нужно изменять структуру таблицы для новых параметров, просто добавьте новую в сценарий развертывания или где бы вы ни настраивали эти параметры.
Мы считаем, что это лучший способ сделать конфигурацию, чем файл, потому что это означает, что вы можете легко программно изменять значения конфигурации через интерфейс администратора, когда это необходимо, что может обеспечить логику того, что может входить в каждую настройку. С файлом это не так просто (хотя, конечно, возможно).
Я могу сказать вам, как я управляю особенно большим приложением на многих сайтах, что хранение конфигураций в локальных файлах - полная боль. Часто конфиги читаются и кэшируются и не могут быть изменены во время выполнения, у других есть горизонтально масштабируемые системы, в которых конфигурации необходимо многократно изменять и возвращать.
Моя жизнь была бы на 10% легче во время реализации системного ландшафта, если бы дизайнеры просто сохранит системные свойства в БД.
Почему каждый раз новая колонка? Почему не только 2 столбца: NAME и VALUE.
Мы устанавливаем значения по умолчанию в файле, а затем отменяем эти значения по умолчанию в базе данных, когда это необходимо, для каждого развертывания.
Кроме того, с точки зрения скорости, мы кэшируем конфигурацию (с возможностью вызвать перезарядку). Нет смысла перечитывать конфигурацию каждый раз, когда вам нужно от нее свойство. Так что с точки зрения скорости это не имеет значения. Вы делаете это один раз.