Таблица базы данных для глобальных настроек

Question

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

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

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

Как это обрабатывается в большинстве случаев, с кем вы имели дело?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

Способ, которым я хотел бы это сделать, если я должен сделать это в базе данных, - хранить атрибуты. Атрибут имеет пару ключ/значение. Но он также имеет тип атрибута (который указывает на таблицу attributeTypes), такую ​​как logging, siteConfig, externalReferences, ... что когда-либо. Затем вы также можете иметь таблицу на уровне AttributeType, которая указывает тип данных, который должен храниться в таблице атрибутов. DataTypeID будет храниться с атрибутами AttributeTypes. Затем это указывает на таблицу DataTypes для поиска. Это позволяет узнать, что вы работаете с числами, датами, строками, xml и т. Д. Я считаю, что это обеспечивает максимальную гибкость ... если вам это нужно.

Answer 5

В ASP.Net вы можете хранить глобальные значения конфигурации в файле Web.Config в парах Name/Value.

Answer 6

Мне нравится подход YAML, который защищает STAii.

Если это приложение .NET или Java, вы также можете рассмотреть XML и использовать сериализацию, чтобы удобно использовать экземпляры ваших пользовательских настроек.

Answer 7

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

пример:

db.name 'MyName'

дб.хозяйничать 'MyHost'

db.user 'MyUser'

db.password 'мойпароль'

теперь я могу получить эти значения, как:

$ config-> db-> имя; или полный массив $ config-> db;

Answer 8

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

1. Используйте строки, чтобы добавить настройки, а не столбцы. Очень легко подумать: «Мне никогда не понадобится больше настроек, чем эти», но вы это сделаете, и это станет гигантским ужасным беспорядком. Я видел это.

2. Вашего Colums должен быть что-то вроде:

   • идентификатора - INT
   • имени - VARCHAR (50)
   • значения - текст
   • тип_данного - VARCHAR (50)
   • описания - текст

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

4. Если возможно, сделайте «имя» уникальной колонкой.

5. Тип данных «текст» соответствует вашим данным, поэтому, когда varchar (50) выделяет 50 символов для каждой строки независимо от того, текст будет регулироваться в зависимости от того, сколько данных имеется. Если ваши данные - что-то простое, как переключатель включения или выключения, это может быть один байт, если это длинный кусок копии, он может облегчить это, не заставляя меньшие данные иметь одинаковый размер. (Я думаю, что так оно и работает, хотя минимальный размер может быть больше одного байта - в любом случае, то, что адаптируется, а не соответствует заранее определенной сумме, безусловно, плюс).

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

7. описание: это комментарии. Используйте это, чтобы сообщить тем, кто придет после вас. ПОЧЕМУ вы сделали то, что сделали, и как избежать сбоя приложения.