1

現在、vb.net でアプリを設計して、バックエンド データベースへのアクセスを操作する予定です。私はデータの冗長性を減らす方法を考えようとしてきました。以下にシナリオの例を示します。

例として、customers テーブルがあり、WI のすべての顧客を強調表示して手紙を送る必要があるとします。顧客テーブルには、すべての顧客と、顧客に関連付けられたプロパティ (名前、住所など) が含まれるため、テーブル内で州が「WI」である場所を照会します。次に、そのデータの結果を取得し、「完了」インジケータを含むテーブルに追加します (つまり、「CUSTOMERS」から「WI_LETTERS」テーブルと言います)。

いくつかの処理を行う必要があると仮定して、完了したら、そのテーブルのフィールドを「完了」としてマークし、手紙を差し込み印刷で印刷できるようにします。('WI_LETTERS' WHERE INDICATOR = COMPLETE から選択)。

そのアイテムは現在完成しています。ただし、奇数年 (2013 年) ごとに、テーブル内の状態が "WI" の全員に通知を送信するとします。年が奇数で、顧客の州が「WI」の場合に、customers テーブルにクエリを実行します。次に、そのデータを「notices」という名前のテーブルに完了インジケータとともに追加すると、完了のマークが付けられます。

データは手元のタスクのみに基づいているため、これはデータを「タスクベース」に保つようです。しかし、これは冗長データと見なされませんか? この設定は、多くのアカウントに対して 1 つのトランザクション タイプが存在する可能性があることを意味します (毎年、同じアカウントに対して複数回も)。しかし、多くのトランザクションに対して 1 つのアカウントであるべきではありませんか?
これのデザインはどのように改善されていますか？

4

1 に答える 1

1

  1. 実行する個々のタスクごとに新しいテーブルの作成を開始したくないことは確かです。追跡する必要がある情報 (したがって、これらのテーブルの列) がタスクの種類によって大きく異なる場合は、タスクの種類ごとにいくつかの異なるテーブルを作成することをお勧めしますが、これらのテーブルは、タスクのすべてのタスクに使用する必要があります。その特定のタイプ。これらのテーブルのフィールドを維持して、各レコードが適用される個々のタスクを識別することができます (たとえば、マーケティング キャンペーン メールアウトの [campaign_id]、または [mail_batch_id] など)。

  2. [WI_letters] のような State (または任意のクライアント属性)によって分離された新しいテーブルの作成を開始したくないことは間違いありません。[Customers] テーブルには既に顧客の State があるため、[Letters] テーブルで必要な顧客関連の属性は [CustomerID] だけです。ウィスコンシン州の顧客への手紙のリストを頻繁に見たい場合は、次のような [WI_Letters] という名前の保存済み(他のデータベース システムでは a と呼ばれることが多い)をいつでも作成できます。QueryView

    SELECT * FROM Letters INNER JOIN Customers ON Customers.CustomerID=Letters.CustomerID WHERE Customers.State="WI"

于 2013-05-28T13:15:53.483 に答える