0

多くの小さなアプリケーションから本質的に構築されたアプリケーションがあります。各アプリケーションには独自の個別の設定がありますが、アプリケーションをナビゲーションに表示するかどうか、公開するかどうか、レポートを生成するかどうかなど、すべて同じ 5 つの設定を共有します。

これらの一般的な設定はすべて、Web アプリのすべてのページで認識される必要があります。これは、ナビゲーションが Web アプリから構築されるためです。そのため、最初はこれらすべての設定を 1 つのテーブルにまとめました。ただし、アプリケーションの数が増えるにつれて (現在は 10、最終的には約 30)、列の数は合計で約 150 ～ 200 になります。これらの列のほとんどはブール値にすぎませんが、1 つのテーブルに多くの列があることは依然として心配です。一方、それらを個別のテーブル (アプリごとの設定) に分割する場合、設定を表示する必要があるたびにそれらをすべて結合する必要があります。

In the application I can break the preferences into smaller objects so they are easier to work with, but from a db perspective they are a single entity. Is it better to leave them in one giant table, or break them apart into smaller ones but force many joins every time they are requested?

4

3 に答える 3

2

どのデータベース エンジンを使用していますか? 通常、DB エンジンのテーブルあたりの推奨列数に関する推奨事項がいくつか見つかります。ほとんどの行サイズの制限により、安全に保つことができます。

その他のオプションと提案は次のとおりです。

  1. 構成キーごとにビットを整数で割り当て、論理「AND」演算を使用して、特定の時点で関心のあるキーのみを表示します。DB から読み取られた単一の値、構成キーの読み取りごとに 1 つの迅速な論理演算。

  2. 設定をメモリにキャッシュし、DB サーバーへのラウンドトリップを減らします。変更の頻度に基づいて、更新時に各設定のキャッシュをクリアする必要がある場合もあります。

于 2012-07-12T12:30:25.243 に答える
1

列を行に変えて、次のようなものを使用してみませんか:

ERD

これは、設定値のリストを維持するための一般的なアプローチです。

APP_SETTINGテーブルには、設定の値が含まれています。このSETTING表は、設定の内容を示しています。

これを拡張して、どの設定がどのアプリケーションに適用されるか、特定の設定の可能な値が特定のリストに制限されているかどうかなどの情報を追加する方法があります。

于 2012-07-12T12:30:38.930 に答える
0

CommonPreferences と ApplicationPreferences は確かに理にかなっており、おそらくコード内でそれらを分離することさえできます (結合ではなく 2 つのクエリ)。

その後、アプリケーションごとのテーブルがより理にかなっています。

別の方法は、ジョエル・ブラウンが提案したルートを下ることです。

3 つ目は、設定ごとに個別の列または行を使用する代わりに、一般的でないものをすべて xml スニペットに詰め込むか、設定クラスからシリアル化します。

どの決定を下すかは、アプリケーションがどのように機能するか (またはデータを使用できるか) に関係しています。設定テーブルのアプローチを下に移動すると、アプリケーション設定を行として取得するのは非常に面倒です。xml スニペット ルートをたどると、複数のアプリケーションにまたがる設定を照会することは、複数の結合よりもさらに困難になります。

ここから何を妥協すべきかはなんとも言えません。最初に CommonPreferences に行き、その後でどこにいたかを確認すると思います。

于 2012-07-12T12:38:49.147 に答える