構成データ：単一行のテーブルと名前と値のペアのテーブル

ユーザーが設定できるアプリケーションを書いたとしましょう。この「構成データ」をデータベースに保存するには、2つのパターンが一般的に使用されます。

1. 単一行のテーブル

     CompanyName  |  StartFullScreen  |  RefreshSeconds  |  ...
   ---------------+-------------------+------------------+--------
     ACME Inc.    |        true       |       20         |  ...
   

2. 名前と値のペアのテーブル

     ConfigOption   |   Value
   -----------------+-------------
    CompanyName     | ACME Inc.
    StartFullScreen | true (or 1, or Y, ...)
    RefreshSeconds  | 20
    ...             | ...
   

両方のオプションを実際に見てきましたが、どちらにも明らかな利点と欠点があります。

• 単一行の表は、使用できる構成オプションの数を制限します（通常、行の列の数は制限されているため）。追加の構成オプションごとに、DBスキーマの変更が必要です。
• 名前と値のペアの表では、すべてが「文字列で入力」されています（ブール値/日付/その他のパラメーターをエンコード/デコードする必要があります）。
• （もっとたくさん）

どのオプションが望ましいかについて、開発コミュニティ内でコンセンサスがありますか？

個人的には、ほとんどの場合、単一行のテーブルを好みます。柔軟性が低いのは事実ですが、動的な動作を想定していない限り、必要に応じて後で列を追加することは完全に受け入れられます。ある意味、これは、辞書/マップを使用して名前と値のペアを保持するのと、プログラミング時にクラスメンバーを保持するのと同じです。確かに、それは完全な比phorではありませんが、それについて考えると、多くの利点と欠点が並行しています。

クラスメンバーに対して辞書/マップを使用しますか？おそらく、表されるデータの量が完全に適応可能であると考える理由がなければ、名前と値のペアテーブルを持っているのと同じです。

通常はオプション2を使用しますが、データ型を適用する複数の列があります

ConfigOption   |   textValue    |   DateValue   |   NumericValue

オプション1には、Active列を追加することで構成全体を非常に簡単に「交換」できるという追加の利点があります。

私にとって、単一行にするかEAVにするかは、それらをどのように消費したいかによって異なります。

EAVの力は、構造を変更せずに新しいデータを追加できることです。つまり、新しい構成値が必要な場合は、テーブルに追加してコード内の必要な場所にそれを引き出すだけで、ドメイン、スキーマ、マッピング、DALクエリに新しいフィールドを追加する必要はありません。など

その欠点は、最も単純な構造しかなく、悲観的にデータを処理する必要があることです。構成値の使用はすべて、値が存在しないか、適切な形式ではないことを予期し、存在しない場合はそれに応じて動作する必要があります。構成値は、double、int、またはcharに解析できない場合があります。nullの場合があります。値の行がまったくない場合があります。これを回避する方法は、通常、特定のコード内タイプのすべての設定値に存在する単一の有効な「デフォルト」値を必要とします（非常にまれです。多くの場合、デフォルト値はコードをまったく消費しないのと同じくらい問題です）、またはデフォルト値のハードコーディングされた辞書を保持します（新しい列が追加されるたびに変更する必要があるため、EAVストレージの主な利点はかなり重要ではありません）。

幅の広い単一の行は、ほとんど反対です。存在するすべての構成値のフィールド/プロパティを使用して、構成オブジェクトの単一インスタンスにマップします。コンパイル時にこれらの値がどのタイプであるかを正確に把握しており、config列が存在しないか適切なタイプの値がない場合、DALで「フェイルファースト」し、例外をキャッチする1つの場所を提供します構成の取得/ハイドレーションの問題。

主な欠点は、新しい値ごとに構造の変更が必要になることです。新しいDB列、DALの新しい列（マッピングまたはSQLクエリ/ SPのいずれか）、新しいドメイン列、すべて使用法を適切にテストするために必要です。

これらのいずれかを使用する適切な状況は、欠点が軽減される状況です。私にとって、構成コーディングのほとんどの状況では、単一行の実装が必要です。これは主に、プログラムの一部の動作を制御するまったく新しい構成値を導入する場合、新しい構成値を使用するようにコードを変更する必要があるためです。なぜ設定オブジェクトにポップして使用する値を追加しませんか？

要するに、構成を保存するEAVスキーマは、それが解決しようとする問題を実際には解決せず、それが提示する問題のほとんどの回避策はDRYに違反します。

特に構成値については、単一の行で行ってください。現在開発中の場合を除き、これらの列はどのくらいの頻度で変更されますか？

large（r）リリース間のダウンタイムにある可能性が低い拡張性のためのコードではなく、valueのデータ型を保護することをお勧めします。また、単一の列を追加または削除することは、最も簡単な移行方法です。新しい構成オプションを作成するときに頭痛の種を予見することはありません。

さらに、「ユーザー」は上限を設定せずにこれらのオプションを設定できると言いました。ユーザーごとの構成ですか？もしそうなら、構成オプションは列にあるべきだとさらに強く主張します-ユーザーごとに1行です。後で多くのメンテナンスの頭痛の種を節約できます。

クライアントがJSONフラグメント（配列や辞書だけでなく、プレーンな文字列、数値、ブール値、null値）を処理できる場合、オプション名とJSONを含む文字列値を持つ複数行のテーブルを作成できます。これにより、構造化された値を保存することもできます。これらの値を処理するコードはすでに存在しているはずです。

クライアントがJSONフラグメントを処理できない場合、新しいクライアントを取得します。

単一行の長所：明確に定義されています。短所：構成を変更するのは大変です。DBの移行など。

Entity-Value Pros：非常に柔軟で、構成の進化をサポートします。短所：参照整合性？コードをさらにチェックして、プロパティで何かを行う前にプロパティが存在するかどうかを確認します。

Mongoのような非リレーショナルデータベースに裏打ちされたアプローチ2を採用します。あなたが確信できる何かがあれば、その変化。

両方を使う！

複数のインスタンスを持つことができるオプションと、一般的なオプションを整理します。

単一行テーブル（構成）

  id  |  company_name  |  start_fullscreen  |  refresh_seconds  |  ...
------+----------------+--------------------+-------------------+-------
  4   |  ACME Inc.     |  true              |  20               |  ...

名前と値のペアのテーブル（オプション）

  name             |  value          | update_time  
-------------------+-----------------+--------------
  generic_option_1 |  Option 1 Value | timestamp    
  generic_option_2 |  Option 2 Value | timestamp    
  generic_option_3 |  Option 3 Value | timestamp    
  configuration    |  4              | timestamp    
  ...              |  ...            | ...          

これはより柔軟だと思います。