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

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

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

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

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

Ответы

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Пример:

db.name 'myname'

db.host 'myhost'

db.user 'myuser'

db.password 'mypassword'

Теперь я могу получить следующие значения:

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

Ответ 6

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

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

  • Ваши Colums должны быть примерно такими:

    • id - int
    • name - varchar (50)
    • значение - текст
    • data_type - varchar (50)
    • описание - текст

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

  • Если возможно, сделайте "имя" уникальным столбцом.

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

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

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

Ответ 7

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

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

Ответ 8

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

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