Использование таблицы конфигурации с одной строкой в ​​базе данных SQL Server. Плохая идея?

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

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

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

Удобный способ хранения информации о конфигурации и / или типе пользовательских предпочтений - в XML . Многие СУБД поддерживают тип данных XML. Синтаксис XML позволяет вам расширять «язык» и структуру, описывающую конфигурацию, по мере ее развития. Одним из преимуществ XML является его неявная поддержка иерархической структуры, позволяющая, например, хранить небольшие списки параметров конфигурации без необходимости называть их нумерованными суффиксами. Возможный недостаток формата XML заключается в том, что поиск и общее изменение этих данных не так просты, как другие подходы (ничего сложного, но не так просто / естественно)

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

EntityId     (foreign key to the "owner" of this attribute)
AttributeId  (foreign key to the "metadata" table where the attribute is defined)
StringValue  (it is often convenient to have different columns of different types
IntValue      allowing to store the various attributes in a format that befits 
              them)

При этом AttributeId является внешним ключом для таблицы, где каждый возможный Attribute («параметр конфигурации» в вашем случае) определяется, скажем,

AttributeId  (Primary Key)
Name
AttributeType     (some code  S = string, I = Int etc.)
Required          (some boolean indicating that this is required)
Some_other_fields   (for example to define in which order these attributes get displayed etc...)

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

Помимо разрешения роста списка возможных параметров конфигурации по мере развития приложения, модель EAV помещает «метаданные», то есть данные, относящиеся к самому атрибуту, в таблицы данных, тем самым избегая жесткого кодирования столбца. имена обычно видны, когда параметры конфигурации хранятся в одной строке.

Обычный способ сделать это - иметь таблицу «свойств», аналогичную файлу свойств. Здесь вы можете хранить все константы вашего приложения или не очень постоянные вещи, которые вам просто нужно иметь под рукой.

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

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "COMPANY_INFO", "Acme Tools", "ADMIN"  
2, 0, 1, "SHIPPING_ID", "12333484", "ADMIN"  
3, 0, 1, "PAYPAL_KEY", "2143123412341", "ADMIN"   
4, 0, 1, "PAYPAL_KEY", "123412341234123", "ADMIN"  
5, 0, 1, "NOTIF_PREF", "ON", "ADMIN"  
6, 0, 2, "NOTIF_PREF", "OFF", "ADMIN"   

Таким образом вы можете сохранить данные, которые у вас есть, и данные, которые будут у вас в следующем году и пока не знаю :).

В этом примере ваша область видимости и refId могут использоваться для всего, что вы хотите, на бэкенде. Итак, если propertyType "ADMIN" имеет область видимости 0 refId 2, вы знаете, какое это предпочтение.

Тип собственности пригодится, когда когда-нибудь вам понадобится хранить здесь и неадминистративную информацию.

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

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

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

Я не уверен, что одна строка - это лучшая реализация для конфигурации. Возможно, лучше иметь строку для каждого элемента конфигурации с двумя колонками (configName, configValue), хотя это потребует приведения всех значений к строкам и обратно.

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

Одна строка будет работать нормально; она даже будет иметь сильные типы:

show_borders    bit
admin_name      varchar(50)
max_users       int

Один недостаток заключается в том, что для добавления новой настройки требуется изменение схемы (alter table). Одной из альтернатив является нормализация, в результате которой вы получаете таблицу типа:

pref_name       varchar(50) primary key
pref_value      varchar(50) 

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