データベース内の構成データをどのように構造化しますか?

https://stackoverflow.com/questions/240428

04-07-2019
|

質問

アプリケーション構成データをデータベースに保存するために人々が好む方法は何ですか。私自身も過去にこれを行ったことがありますが、2 つの方法を利用しました。

キーと値のペアを保存するテーブルを作成できます。キーは構成オプションの名前、値はその値です。これの長所は、新しい値の追加が簡単で、同じルーチンを使用してデータを設定/取得できることです。欠点は、値として型指定されていないデータがあることです。
あるいは、各列が値の名前とそのデータ型である構成テーブルをハードコーディングすることもできます。これの欠点は、新しい値を設定するためのメンテナンスが増えることですが、データを型指定することができます。

両方を使用したので、私の好みは最初のオプションです。設定が迅速ですが、リスクも高く、データ検索時のパフォーマンスが (わずかに) 低下する可能性があります。誰かが代替方法を持っていますか?

アップデート

以下で説明するように、同じ方法で構成する必要があるプログラムのインスタンスが複数存在したり、同じ値を使用する可能性のあるストアドプロシージャが存在する可能性があるため、情報をデータベースに保存する必要があります。

解決

オプション1を展開して、3番目の列にデータ型を指定できます。アプリケーションでは、このデータ型の列を使用して値をキャストできます。

しかし、ええ、構成ファイルがオプションでない場合は、オプション1を使用します。オプション1のもう1つの利点は、アプリケーションで非常に簡単に使用できるように、Dictionaryオブジェクト（または同等の）に読み込むことができることです。

他のヒント

通常、構成はテキストファイルに格納できるため、文字列データ型は構成値を格納するのに十分な大きさでなければなりません。マネージ言語を使用している場合、データベースではなく、データ型がどうあるべきかを知っているのはコードです。

さらに重要なことは、設定でこれらのことを考慮してください：

階層：明らかに、構成は階層
バージョン管理：特定の日付に有効だった構成にロールバックできる利点を考慮してください。
配布：しばらくの間、アプリケーションをクラスター化できると便利な場合があります。一部のプロパティは、おそらくクラスタ内の各ノードに対してローカルである必要があります。
ドキュメント：Webツールなどがあるかどうかによっては、プロパティに関するドキュメントを、それを使用するコードの近くに保存するのがよいでしょう。（これにはコード注釈が非常に便利です。）
通知：構成リポジトリのどこかで変更が行われたことをコードはどのように知るのですか？

個人的には、設定を処理する逆の方法が好きです。設定プロパティは、値がどこから来たかわからないモジュールに注入されます。このように、構成管理システムは（現在の）ニーズに応じて非常に複雑または非常に単純になります。

オプション1を使用します。

構成データにDBを使用するのはやり過ぎのようです。

編集（コメントボックスには長すぎます）：もちろん、プログラムのどの部分を実装するかについての厳密なルールはありません。議論のために、マイナスドライバーはいくつかのフィリップスネジで動作します！あなたのシナリオが何であるかを知る前に、私は早すぎる判断をしたと思います。

リレーショナルデータベースは大規模なデータストアに優れているため、保存、更新、取得を迅速に行うことができます。したがって、構成データが常に更新および読み取りされる場合は、必ずdbを使用してください。

dbが理にかなっているもう1つのシナリオは、データベースに中央構成を保存するサーバーファームがある場合ですが、xml構成ファイルを指す共有ネットワークドライブでも同じことができます。

XMLファイルは、構成が階層構造になっている場合に適しています。必要なものを簡単に整理、検索、および更新できます。また、ボーナスメリットとして、構成ファイルをソースコードとともにバージョン管理できます。

全体として、すべては構成データの使用方法に依存します。

これで、私の意見はあなたの申請についての限られた知識で終わります。あなたが正しい決定を下せると確信しています。

これは世論調査に近いと思うので、列アプローチ（オプション2）を使用します。ただし、設定の変更頻度、設定の動的さ、データの量などに依存します。

私は確かにユーザーの設定/設定などにこのアプローチを使用します

私のプロジェクトでは、4つの列を持つデータベーステーブルを使用しています：

ID [pk]
スコープ（デフォルトは「アプリケーション」）
設定
値

スコープが「アプリケーション」の設定は、同時ユーザーの最大数などのグローバル設定です。

各モジュールには、独自のスコープベースがあります。そのため、ResultsLoaderとUserLoaderのスコープは異なりますが、両方とも「inputPath」という名前の設定があります。

デフォルトは、ソースコードで提供されるか、IoCコンテナを介して注入されます。データベースに値が挿入または提供されない場合、コードのデフォルトが使用されます（存在する場合）。したがって、デフォルトがデータベースに保存されることはありません。

これは私たちにとって非常にうまく機能します。データベースをバックアップするたびに、非常に便利な構成のコピーを取得します。この2つは常に同期しています。

オプション2に進みます。オプション1は、実際にデータベースの上にデータベースを実装する方法であり、よく知られているアンチパターンであり、長期的には問題を引き起こすだけです。

少なくとも2つの方法を考えることができます：

（a）キー、文字列値、日付値、整数値、実数値の列を持つテーブルを作成します。未使用の型はNULLのままにします。

（b）XML、YAML、JSONなどのシリアル化形式を使用して、すべてをblobに保存します。

アプリがデータベースに接続するために必要な構成設定はどこに保存しますか？

他の設定情報も保存しないのはなぜですか？

設定オプションの数が非常に少ない（7以下）場合を除き、オプション1を使用します

私の会社では、オプション1（簡単な辞書のようなテーブル）をひねりながら使用することに取り組んでいます。置換される構成変数の名前を含むトークンを使用した文字列置換を許可しています。

たとえば、テーブルには行（「データベース接続文字列」、「jdbc：//％host％...」）および（「ホスト」、「foobar」）が含まれる場合があります。それを単純なサービスまたはストアドプロシージャレイヤーでカプセル化すると、非常にシンプルですが、柔軟な再帰的な構成が可能になります。複数の隔離された環境（dev、test、prodなど）を持つ必要性をサポートします。

過去に1と2の両方を使用しましたが、どちらもひどい解決策だと思います。入力できるので、オプション2の方が良いと思いますが、オプション1よりもいです。どちらかで最も大きな問題は、構成ファイルのバージョン管理です。標準のバージョン管理システムを使用して、SQLを適切にバージョン管理できますが、通常、変更のマージには問題があります。これを「正しく」行う機会を考えると、おそらく構成パラメーターのタイプごとに1つ（必ずしもパラメーター自体ごとではない）のテーブルの束を作成するので、入力の利点とキー/必要に応じて値のパラダイム。リストや階層など、この方法でより高度な構造を実装することもできます。これらの構造は、設定を読み込んでメモリ内で何らかの形で変換する代わりに、アプリによって直接クエリ可能になります。

オプション2に投票します。理解と保守が簡単です。

オプション1は、簡単に拡張可能な中央保管場所に適しています。 RB、ヒューゴ、エリオットなどの人々による優れたコラムの提案に加えて、次のことも検討できます。

グローバル/ユーザー設定フラグをユーザーフィールドまたはユーザー/マシンフィールドに含めます（マシン固有のUIタイプ設定用）。

もちろん、これらはローカルファイルに保存できますが、データベースを使用しているため、デバッグ時にユーザーのエイリアスに使用できます。これは、バグが設定に関連している場合に重要です。また、管理者は必要に応じて設定を管理できます。

SQL サーバーではオプション 2 と XML 列を組み合わせて使用しています。テーブルを 1 行に保つためのチェック制約を追加したくない場合もあります。

CREATE TABLE [dbo].[MyOption] (
  [GUID] uniqueidentifier CONSTRAINT [dfMyOptions_GUID] DEFAULT newsequentialid()  ROWGUIDCOL NOT NULL,
  [Logo] varbinary(max) NULL,
  [X] char(1)  CONSTRAINT [dfMyOptions_X] DEFAULT 'X' NOT NULL,
  CONSTRAINT [MyOptions_pk] PRIMARY KEY CLUSTERED ([GUID]),
  CONSTRAINT [MyOptions_ck] CHECK ([X]='X')
)

dbテーブルとは関係のない設定の場合、値を使用してdbを使用する必要がある場合は、おそらくEAVアプローチを使用します。そうでない場合、シリアル化されたフィールド値は、アプリコードの単なるストアである場合に適しています。

しかし、dbによって使用される複数の構成設定を保存する単一フィールドのフォーマットはどうですか？

メッセージボードビューに関連するすべての設定（デフォルトの並べ替え順序、ブロックされたトピックなど）を含むユーザーごとのフィールドと、テーマのすべての設定（テキストの色、背景色など）を含むフィールド。）

階層とドキュメントをリレーショナルDBに保存するのは狂気です。まず、それらを細断する必要がありますが、後の段階で再結合するだけです。または、BLOBの中にさらにバカなものがあります。

非リレーショナルデータにリレーショナルデータベースを使用しないでください。ツールは適合しません。これにはMongoDBやCouchDBのようなものを検討してください。スキーマレスの非リレーショナルデータストア。何らかの方法でクライアントに送信される場合はJSONとして保存し、サーバーサイドでXMLを使用します。

CouchDBは、そのままバージョン管理を提供します。

特別な理由がない限り、データベースに構成データを保存しないでください。非常に正当な理由があり、それを行うことを絶対に確信している場合は、アプリを設定するために実際にマークアップ言語が必要な場合を除き、おそらくJSONやYAML（XMLではなく）のようなデータシリアル化形式で保存する必要があります- -私を信じてください、あなたはそうではありません）文字列として。その後、文字列を読むだけで、使用する言語のツールを使用して文字列を読み取り、変更できます。タイムスタンプ付きの文字列を保存すると、非常にシンプルなシステムに階層データを保存する機能を備えたシンプルなバージョン管理スキームができます。階層的な構成データが不要な場合でも、少なくとも現在必要な場合は、それを取得するために構成インターフェースを変更する必要はありません。もちろん、構成データに対してリレーショナルクエリを実行することはできませんが、多くの構成データを格納している場合は、とにかく非常に間違ったことをしている可能性があります。

企業は、システムの多くの構成データをデータベースに保存する傾向があります。なぜかはわかりませんが、これらの決定についてはあまり考えられないと思います。 OSSの世界では、このようなことはあまり頻繁に行われません。 Apacheのような多くの設定を必要とする大規模なOSSプログラムでさえ、apache_configテーブルを含むデータベースへの接続は必要ありません。アプリで処理する大量の設定があると、コードの悪臭がします。そのデータをデータベースに保存すると、より多くの問題が発生します（このスレッドが示すように）。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow