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

Question

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

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

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

Обновление

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

Answer 1

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

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

Answer 2

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

Что еще более важно, рассмотрите эти вещи с конфигурацией:

• Иерархия : Очевидно, что конфигурация выиграет от иерархия
• Управление версиями : рассмотрите преимущество возможности отката к конфигурации, которая действовала на определенную дату.
• Распространение : Когда-нибудь было бы неплохо иметь возможность кластеризовать приложение. Некоторые свойства должны быть локальными для каждого узла в кластере.
• Документация : В зависимости от того, есть ли у вас веб-инструмент или что-то еще, вероятно, будет полезно хранить документацию о свойстве рядом с кодом, который его использует. (Аннотации кода очень хороши для этого.)
• Уведомление : Как код узнает, что было внесено изменение где-то в хранилище конфигурации?

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

Answer 3

Кажется излишним использовать БД для данных конфигурации.

РЕДАКТИРОВАТЬ (извините, слишком долго для комментария): Конечно, нет строгих правил относительно того, как вы реализуете какую-либо часть своей программы. Ради аргумента, шлицевые отвертки работают на некоторых винтах Philips! Думаю, я судил слишком рано, прежде чем узнал, каков твой сценарий.

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

Другой сценарий, в котором db может иметь смысл, - это когда у вас есть ферма серверов, где вы хотите, чтобы ваша база данных хранила вашу центральную конфигурацию, но затем вы можете сделать то же самое с общим сетевым диском, который указывает на файл конфигурации xml.

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

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

На этом мое мнение заканчивается ограниченным знанием вашей заявки. Я уверен, что вы можете принять правильное решение.

Answer 4

Я использую вариант 1.

Answer 5

В моем проекте используется таблица базы данных с четырьмя столбцами:

1. ID [pk]
2. Область (по умолчанию «Приложение»)
3. Настройка
4. Value

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

Каждый модуль имеет свою собственную область действия; поэтому наши ResultsLoader и UserLoader имеют разные области видимости, но оба имеют параметр с именем inputPath.

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

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

Answer 6

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

Я бы, конечно, использовал этот подход для пользовательских настроек / предпочтений и т. Д.

Answer 7

Я могу придумать еще как минимум два способа:

(a) Создайте таблицу со столбцами ключ, строковое значение, значение даты, int-значение, действительное значение. Оставьте неиспользованные типы NULL.

(b) Используйте формат сериализации, такой как XML, YAML или JSON, и сохраните все это в BLOB-объекте.

Answer 8

Перейти с вариантом 2. Вариант 1 на самом деле является способом реализации базы данных поверх базы данных, и это хорошо известный антипаттерн, который в конечном итоге создаст вам проблемы.

Answer 9

для настроек, которые не имеют отношения к таблицам БД, я бы, вероятно, выбрал подход EAV, если вам нужна БД для работы со значениями. в противном случае сериализованное значение поля хорошо, если это просто хранилище кода приложения.

а как насчет формата для одного поля для хранения нескольких настроек конфигурации, которые будут использоваться БД?

как одно поле для каждого пользователя, которое содержит все его настройки, связанные с его представлением на доске объявлений (например, порядок сортировки по умолчанию, заблокированные темы и т. Д.), И, возможно, другое со всеми настройками для их темы (например, цвет текста, цвет bg и т. Д.) .)

Answer 10

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

CREATE TABLE [dbo].[MyOption] (
  [GUID] uniqueidentifier CONSTRAINT [dfMyOptions_GUID] DEFAULT newsequentialid()  ROWGUIDCOL NOT NULL,
  [Logo] varbinary(max) NULL,
  [X] char(1)  CONSTRAINT [dfMyOptions_X] DEFAULT 'X' NOT NULL,
  CONSTRAINT [MyOptions_pk] PRIMARY KEY CLUSTERED ([GUID]),
  CONSTRAINT [MyOptions_ck] CHECK ([X]='X')
)