SQL Serverデータベースで単一行構成テーブルを使用する。悪いアイデア？

ショッピングカートアプリケーションを開発する際に、管理者の好みと要件に基づいて設定と構成を保存する必要があることがわかりました。この情報には、会社情報、配送アカウントID、PayPal APIキー、通知設定などが含まれます。

リレーショナルデータベースシステムで単一の行を格納するテーブルを作成することは非常に不適切と思われます。

この情報を保存する適切な方法は何ですか？

注：私のDBMSはSQL Server 2008で、プログラミングレイヤーはASP.NET（C＃）で実装されています。

過去にこれを2つの方法で行いました-単一行テーブルとキー/値ペアテーブル-それぞれのアプローチには良い点と悪い点があります。

単列

• 正：値は正しいタイプで保存されます
• ポジティブ：（上記の理由により）コードで処理するのが簡単です
• 正：デフォルト値を各設定に個別に与えることができます
• 否定：新しい設定を追加するにはスキーマの変更が必要です
• 負：設定が多い場合、テーブルが非常に広くなる可能性があります

キー/値ペア

• ポジティブ：新しい設定を追加するためにスキーマを変更する必要がない
• ポジティブ：テーブルスキーマは狭く、新しい設定に追加の行が使用されます
• 負：各設定のデフォルト値は同じ（null / empty？）
• 否定：すべてを文字列として保存する必要があります（つまり、nvarchar）
• ネガティブ：コードで設定を処理するときは、設定のタイプを知ってキャストする必要があります

単一行オプションは、操作するのがはるかに簡単です。これは、各設定をデータベースの正しいタイプで保存でき、設定のタイプとルックアップキーをコードに保存する必要がないためです。

このアプローチを使用する際に心配したことの1つは、「特別な」単一行設定テーブルに複数の行があることでした。（SQL Serverで）私はこれを克服しました：

• デフォルト値0の新しいビット列を追加する
• この列の値が0であることを確認するためのチェック制約を作成する
• ビット列に一意の制約を作成する

これは、ビット列の値が0でなければならないため、テーブルに存在できる行は1つだけですが、一意の制約のため、その値を持つ行は1つしか存在できないことを意味します。

（少なくとも）情報タイプと情報値の列を持つテーブルを作成する必要があります。これにより、新しい情報が追加されるたびに新しい列を作成する必要がなくなります。

1つの行で問題なく動作します。それは強い型さえ持っています：

show_borders    bit
admin_name      varchar(50)
max_users       int

1つの欠点はalter table、新しい設定を追加するためにスキーマの変更（）が必要になることです。代替案の1つは、次のようなテーブルになる正規化です。

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

これには弱い型（すべてがvarchar）がありますが、新しい設定を追加することは、単に行を追加することであり、データベースの書き込みアクセスだけで実行できるものです。

個人的には、それが機能する場合は1行に格納します。それをSQLテーブルに格納するのはやり過ぎですか？おそらく、そうすることで実際に害はありません。

ご想像のとおり、最も単純な状況を除いて、すべての構成パラメーターを単一の行に配置することには多くの欠点があります。それは悪い考えです...

構成やユーザー設定タイプの情報を格納する便利な方法はXMLです。多くのDBMSがXMLデータ型をサポートしています。XML構文を使用すると、構成が進化するにつれて、構成を記述する「言語」と構造を拡張できます。XMLの利点の1つは、階層構造を暗黙的にサポートすることです。たとえば、番号付きのサフィックスを使用して名前を付けなくても、構成パラメーターの小さなリストを格納できます。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は、可能な各属性（ここでは「構成パラメータ」）が定義されているテーブルへの外部キーです。

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を使用すると、これらのさまざまな属性を「所有」するエンティティを特定できます。あなたの場合、管理する構成が1つしかない場合、それはUserIdである可能性があります。

EAVモデルは、アプリケーションの進化に伴って可能な構成パラメーターのリストを拡張できるようにするほかに、「メタデータ」、つまり属性自体に関連するデータをデータテーブルに配置するため、一般的に見られる列名のすべてのハードコーディングを回避できます構成パラメーターが単一行に格納されている場合。

正規化されたアプローチで新しい構成パラメーターを追加するときにスキーマを変更する必要はありませんが、おそらく新しい値を処理するようにコードを変更しています。

デプロイメントに「代替テーブル」を追加することは、単一行アプローチの単純さとタイプセーフティのトレードオフのように大きくは思えません。

キーと値のペアは、構成設定を保存できる.Net App.Configに似ています。

したがって、値を取得する場合は、次のようにします。

SELECT value FROM configurationTable
WHERE ApplicationGroup = 'myappgroup'
AND keyDescription = 'myKey';

これを行う一般的な方法は、プロパティファイルに似た「プロパティ」テーブルを用意することです。ここには、すべてのアプリの定数を格納するか、必要なだけの定数ではないものを格納できます。

その後、必要に応じてこのテーブルから情報を取得できます。同様に、他に保存する設定があることがわかった場合は、それを追加できます。次に例を示します。

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を保存する場合は、次のようなテーブルを使用します。そうすることで、アプリをアップグレードする必要があるときに、プロパティテーブルをチェックして、クライアントにあるソフトウェアのバージョンを確認できます。

ポイントは、カートに関連するものにこれを使用しないことです。明確に定義されたリレーショナルテーブルでビジネスロジックを維持します。プロパティテーブルはシステム情報専用です。

単一の行が構成に最適な実装であるかどうかはわかりません。2つの列（configName、configValue）を持つ構成アイテムごとに1行を持つことをお勧めしますが、これにはすべての値を文字列にキャストして戻す必要があります。

いずれにしても、グローバル設定に単一の行を使用しても害はありません。それをDBに格納するためのその他のオプション（グローバル変数）のほうが適しています。最初の構成行を挿入し、テーブルの挿入を無効にして複数の行を防ぐことで、それを制御できます。

主要なタイプごとに1つの列と、データがどの列にあるかを示す1つの列を追加することにより、変換なしでキーと値のペアを実行できます。

したがって、テーブルは次のようになります。

id, column_num, property_name, intValue, floatValue, charValue, dateValue
1, 1, weeks, 51, , ,
2, 2, pi, , 3.14159, , 
3, 4, FiscYearEnd, , , , 1/31/2015
4, 3, CompanyName, , , ACME, 

それはもう少し多くの部屋を使用しますが、多くても数十の属性を使用しています。column_num値のcaseステートメントを使用して、正しいフィールドをプル/結合できます。

すみません、そうです、後で。とにかく、私がすることはシンプルで効果的です。3つの（）列を持つテーブルを作成するだけです。

ID-整数（11）

名前-varchar（64）

値-テキスト

新しい構成列を作成、更新、または読み取る前に行うことは、「値」をシリアル化することです。このように私はタイプを確信しています（まあ、phpは:)です）

例えば：

b：0; B OOLEAN 用です（false）

b：1; B OOLEAN 用です（true）

i：1988; 私は NT 用です

s：5： "Kader"; 5文字の長さのS TRING 用です

これが役に立てば幸いです:)

キー列をvarcharとし、値列をJSONとします。1は数値"1"ですが、文字列です。trueとfalseブール値です。オブジェクトを持つこともできます。