1

さまざまなドキュメント タイプに関するメタデータを格納できるコンテンツ管理システムを作成しています。各ドキュメント タイプには、独自のメタデータ フィールドのセットがあります。たとえば、レターには「To」、「From」、「ToAddress」、「FromAddress」などのフィールドがあり、MinutesOfMeeting には「DateHeldOn」、「TimeHeldOn」、「AttendedBy」などのフィールドがあります。

この情報を、一般と特定の 2 つのテーブルでデータベースに保存しています。DocumentOwnerName、DocumentCreatedDate、DocumentSize など、すべてのタイプに共通する一般的なストア情報。特定のテーブルは 1 つのテーブルではなく、ドキュメント タイプごとに 1 つずつ、35 の異なるテーブルのセットです。

ドキュメントのリストを表示するグリッドを含むページがあります。1 つのレコードが 1 つのドキュメントに対応します。グリッドはすべてのタイプの文書を表示するように作られているため、最初の行には手紙、2 番目に議事録、3 番目にメモなどを表示できます。

また、取得するドキュメント リストに基づいてユーザーが基準を設定できる検索機能も作成しました。これを機能させるために、特定の各テーブルのフィールドごとに 4 つの検索関連パラメーターがあり、これらのパラメーターはすべて中央プロシージャーに渡されます。次に、このプロシージャは基準に基づいてレコードを除外します。

問題は、それぞれが 10 個のフィールドを持つ 35 の異なるドキュメント タイプを処理することで、プロシージャのパラメーターが 1,000 を超えてしまうことです。これはメンテナンスの悪夢です。私は解決策を探しています。

1 つの解決策は、特定のテーブルのそれぞれを個別に処理し、ID を取得してから結合することです。これは問題ありませんが、データベースに対して 36 回の異なる呼び出しを行う必要があることを除けば、それぞれ特定のテーブルに対して 1 回と一般的なテーブルに対して 1 回です。

それはすべて単純なアーキテクチャの選択に要約されます: 多くのパラメーターを渡す単一のデータベース呼び出しを行うべきか、それとも少数のパラメーターを渡す多くのデータベース呼び出しを行うべきか。

どちらのアプローチがより好ましいですか?またその理由は?

編集: web-server と database-server は同じマシン上にあります。したがって、ネットワーク速度は重要ではありません。

4

1 に答える 1

1

多数の関連パラメータ、またはパラメータの変数リストを取得する手順が必要な API を設計する場合、次のようなレコード タイプを使用します。

TYPE param_type IS RECORD (
   To
   From
   ToAddress
   FromAddress
   DateHeldOn
   TimeHeldOn
   AttendedBy
);

PROCEDURE do_search (in_params IN param_type);

もちろん、レコードの構造はあなた次第です。プロシージャが NULL のレコード要素を無視するようにコーディングされている場合、呼び出し元が行う必要があるのは、必要な要素を設定することだけです。次に例を示します。

DECLARE
   p param_type;
BEGIN
   p.DateHeldOn := DATE '2012-01-01';
   do_search(p);
END;
于 2012-04-23T05:25:28.593 に答える