Как вы структурируете данные конфигурации в базе данных?

Question

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

1. Вы можете создать таблицу, в которой хранятся пары ключ / значение, где ключ - это имя параметра конфигурации, а значение - его значение. Преимущества этого в том, что добавлять новые значения легко, и вы можете использовать те же процедуры для установки / получения данных. Недостатки: у вас нетипизированные данные в качестве значения.
2. Кроме того, вы можете жестко закодировать таблицу конфигурации, в которой каждый столбец является именем значения и его типом данных. Недостатком этого является более сложная настройка новых значений, но она позволяет вводить данные.

Используя оба, мои предпочтения связаны с первым вариантом, так как он быстрее настраивает, но также более рискован и может немного снизить производительность при поиске данных. У кого-нибудь есть альтернативные методы?

Обновление

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

Answer 1

Вариант 1 подходит для легко расширяемого центрального хранилища. В дополнение к некоторым замечательным предложениям от таких людей, как RB, Hugo и elliott, вы также можете рассмотреть следующие вопросы:

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

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

Answer 2

Я голосую за вариант 2. Легко понять и поддерживать.

Answer 3

Я использовал 1 и 2 в прошлом, и я думаю, что они оба ужасные решения. Я думаю, что вариант 2 лучше, потому что он позволяет печатать, но он намного страшнее, чем вариант 1. Самая большая проблема, с которой я сталкиваюсь, - это версия файла конфигурации. Вы можете достаточно хорошо создавать версии SQL, используя стандартные системы контроля версий, но объединение изменений обычно проблематично. Если бы у меня была возможность сделать это «правильно», я бы, вероятно, создал несколько таблиц, по одной для каждого типа параметра конфигурации (не обязательно для каждого параметра), получая таким образом преимущество ввода и преимущества ключа / значения. парадигма, где это уместно. Вы также можете реализовать более сложные структуры, такие как списки и иерархии, которые затем будут напрямую запрашиваться приложением, вместо того, чтобы загружать конфигурацию и затем каким-то образом преобразовывать ее в память.

Answer 4

Я бы выбрал вариант 1, если только число параметров конфигурации не было ОЧЕНЬ маленьким (семь или меньше)

Answer 5

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

Почему бы не хранить там другую информацию о конфигурации?

Answer 6

Хранение иерархии и документов в реляционной БД - это безумие. Во-первых, вы должны либо уничтожить их, но затем объединить на более позднем этапе. Или там, загнутый внутрь BLOB, еще глупее.

Не используйте реляционные БД для нереляционных данных, инструмент не подходит. Для этого рассмотрим что-нибудь вроде MongoDB или CouchDB. Безрецептурные нереляционные хранилища данных. Сохраните его как JSON, если он каким-либо образом подключается к клиенту, используйте XML для серверной части.

CouchDB дает вам версии из коробки.

Answer 7

Не храните данные конфигурации в базе данных, если у вас нет для этого веских причин. Если у вас есть очень веская причина, и вы абсолютно уверены, что собираетесь это сделать, вам, вероятно, следует хранить ее в формате сериализации данных, таком как JSON или YAML (не XML, если вам не нужен язык разметки для настройки приложения - - Поверь мне, ты не) как строка. Затем вы можете просто прочитать строку и использовать инструменты на любом языке, на котором вы работаете, чтобы читать и изменять его. Храните строки с временными метками, и у вас есть простая схема управления версиями с возможностью хранить иерархические данные в очень простой системе. Даже если вам не нужны иерархические данные конфигурации, по крайней мере сейчас, если они понадобятся вам в будущем, вам не придется менять интерфейс конфигурации, чтобы получить их. Конечно, вы теряете возможность выполнять реляционные запросы к вашим данным конфигурации, но если вы храните этих больших данных конфигурации, то вы, вероятно, все равно делаете что-то очень неправильное.

Компании, как правило, хранят множество данных конфигурации для своих систем в базе данных, я не уверен, почему, я не думаю, что много думают об этих решениях. Я не вижу, чтобы подобные вещи делали слишком часто в мире OSS. Даже большие программы OSS, которые нуждаются в большом количестве настроек, таких как Apache, не нуждаются в подключении к базе данных, содержащей таблицу apache_config, для работы. Наличие большого количества настроек в ваших приложениях - неприятный запах кода, хранение этих данных в базе данных просто вызывает больше проблем (как иллюстрирует этот поток).

Answer 8

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

Например, таблица может содержать строки («строка подключения к базе данных», «jdbc: //% host% ...») и («host», «foobar»). Инкапсуляция этого с помощью простого уровня обслуживания или хранимых процедур обеспечивает чрезвычайно простую, но гибкую рекурсивную конфигурацию. Он поддерживает нашу потребность в нескольких изолированных средах (dev, test, prod и т. Д.).