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

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

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

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

Обновление

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

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

Я использую параметр 1.

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

ID [pk]
Область действия (по умолчанию "Приложение" )
Установка
Значение

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

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

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

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

Ответ 7

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

Ответ 8

Я могу подумать хотя бы о двух способах:

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

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

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

Ответ 15

Я использую сочетание столбцов опций 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')
)

Ответ 16

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

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

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

Ответ 17

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

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

CouchDB дает вам возможность выпуска версий из коробки.

Ответ 18

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

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