8

多くの場合、管理者情報やバージョンなどのシステムプロパティを保存する必要がある場合は、フラットファイル（database.properties、init.propertiesなど）を使用します。これは、私が日常的に見たり使用したりしている他のプログラムでは一般的なようです。

フラットファイルは、いくつかの理由で理想的でない場合があります。多くの場合、Webアプリを多数のクライアントにデプロイするには制限があります。このような場合、データベーステーブルを使用して情報を保持します。たとえば、保存したい管理データがいくつかあり、環境に関する詳細がいくつかあるとします。私はこのようなことをするかもしれません：

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "DB_VER", "2.3.0", "FLOAT"  
2, 0, 1, "LICENCE", "88475", "INT"  
3, 0, 1, "TOP_PROJECT", "1", "INT"   
4, 0, 1, "SHOW_WELCOME", "F", "BOOL"  
5, 0, 1, "SMTP_AUTH", "SSH", "STRING"  
6, 1, 1, "ADMIN_ALERTS", "T", "BOOL"

これによりSQLの型指定が壊れ、あらゆる種類の型を文字列として保存できるようになります。これは良い習慣ですか、それとも私はこれを間違った方法で行っていましたか？

そうでない場合、このタイプの情報をどのように保存する必要がありますか？

4

3 に答える 3

2

これは問題ないと思いますが、DBに戻り続ける必要がないように、データを読み取るときにデータをメモリにキャッシュすることを検討することをお勧めします。データをキャッシュする場合は、更新が最も簡単になる場所にデータを保存します。DBにデータを格納することの利点は、特にアプリケーションで分散環境の使用を開始すると、これらのプロパティを管理するためのインターフェイスの保守または作成が容易になる可能性があることです。

于 2010-02-23T19:35:48.640 に答える
1

プロパティデータを格納するために同様の構造を使用しましたが、テーブルが比較的小さいままであれば問題ないと思います。このようなentity-attribute-value（EAV）テーブルは、従来の列構造のテーブルよりも多くのスペースを消費し、クエリのパフォーマンスが低下する可能性がありますが、適度なサイズのアプリケーションプロパティのセットでは問題になりません。

于 2010-02-23T19:22:03.713 に答える
0

これは、アクセス頻度の低い少量のデータには問題ありません。

実際には、スキーマを見ているユーザーにとって、個々のアプリのプロパティが表示されない方がよい場合があります。

これにより、スキーマの更新に関する問題が軽減されます。（アプリのプロパティは頻繁に追加/削除されます。）

データベースが取得ごとにここで実行する作業がはるかに多く、従来のスキーマよりも多くのスペースが占有されるため、大量のデータや頻繁にアクセスされるデータには適していません。

于 2010-02-23T19:27:31.543 に答える