sql - Table Design For SystemSettings, Best Model

Question

Someone suggested moving a table full of settings, where each column is a setting name(or type) and the rows are the customers & their respective settings for each setting.

ID | IsAdmin | ImagePath
------------------------------
12 | 1          | \path\to\images
34 | 0          | \path\to\images

The downside to this is every time we want a new setting name(or type) we alter the table(via sql) and add the new (column)setting name/type. Then update the rows(so that each customer now has a value for that setting).

The new table design proposal. The proposal is to have a column for setting name and another column for setting.
ID | SettingName | SettingValue
----------------------------
12 | IsAdmin        | 1
12 | ImagePath   | \path\to\images
34 | IsAdmin        | 0
34 | ImagePath   | \path\to\images

The point they made was that adding a new setting was as easy as a simple insert statement to the row, no added column.

But something doesn't feel right about the second design, it looks bad, but I can't come up with any arguments against it. Am I wrong?

Answer 1

これは、「エンティティ属性値」スキーマのバリエーションです（JoelおよびランダムSO質問）

それにはいくつかの長所と短所があり、涙で終わることがほぼ保証されています。

Answer 2

2 番目のアプローチは、実際には辞書に似ています。あなたが言及した理由から、これは私が取り組んでいるアプリケーションにとってより便利な選択であることがわかりました. このアプローチにはいくつかの注意点があるため、注意が必要です。

• キー文字列を静的に保ち、名前を変更しないでください。
• 設定ディクショナリが取得されるたびに、必ず最新バージョンに更新してください (通常はキーを追加し、デフォルト値を設定するか、ユーザーにプロンプ​​トを表示します)。
• 文字列と 10 進データなどを混在させるのは困難です。適切な形式でデータを格納できるように、1 つを選択するか、複数の null 許容列を提供する必要があります。そのメタデータをどこかに保管しておいてください。
• ディクショナリを扱うコードは、強く型付けされた方法でそれをラップし、(データ構造の意味で) 実際のディクショナリとして決して公開せず、代わりにクラスを提供する必要があります。

Answer 3

列名を使用して設定を区別することは、通常、ひどい考えです。扱っているエンティティは SETTING で、属性 NAME と VALUE を持っています。異なるコンテキストで同じ名前を使用する必要がある場合は、SETTING を階層的にします。つまり、ルート以外の各設定が親になります。顧客はルートを親として持つことができ、各顧客の下のパスは各設定で同じになります。必要に応じて、追加のデータ型に別の列を使用できます。