4

ここでの私の最初の質問です。

私は経験の浅い開発者で、この問題に悩まされています。

監査可能にする必要があるテーブルがあります。このテーブルに、コール センターからの電話が記録されているとします (そうではありませんが、これは単なる例です)。私はそれを「CallHistory」と呼びます。

私は当初、呼び出し先の名前、電話番号などを含む「Callees」という別のテーブルを保持することを計画していました。このテーブルは代理主キーを使用します。

CallHistory テーブルには、Callee テーブルへの外部キーがあります。

もともとこれを行ったのは、呼び出し先の電話番号を変更すると、システム全体に伝播し、複数のテーブルで電話番号を変更する必要がなくなるためです。

問題は、CallHistory テーブルの要点は、ダイヤルミス (発信者が間違った番号をダイヤルしたなど) を含む通話の履歴を記録することです。この代理キー アプローチを使用すると、履歴が失われます。

職場の上級開発者の 1 人は、履歴を保存するために、特定の時間に発信者がダイヤルするたびに電話番号のコピーを CallHistory テーブルに保持することを提案しました。

同じ目的で監査/変更ログテーブルを保持することを考えていました。

私のアプローチはこの目的に十分でしょうか、それとも完全に軌道から外れていますか? どちらのアプローチを好みますか?

乾杯、アンドリュー

4

3 に答える 3

2

ここでの通常のフォームに関する微妙な点に惑わされていると思います。問題は、着信者に関連付けられた電話番号は、発信者がダイヤルした番号と同じ情報ではないということです。一般的には同じ値になる可能性がありますが、これは別の問題です。

したがって、私の意見では、CallHistory には、ダイヤルされた番号と呼び出し先テーブルへの参照の両方が必要です。

于 2009-08-17T09:23:13.320 に答える
1

私はリックに同意します。はい、冗長データは非常に、非常に悪い、悪、臭い、その他の点で望ましくありません。しかし、2つのフィールドが「電話番号」と呼ばれているからといって、同じものになるわけではありません。「お客様の現在の電話番号」と「最後にお客様と話をしたときのお客様の電話番号」は、必ずしも同じものではありません。

私は現在、販売とアイテムの情報を保持するデータベースを使用しています。アイテムレコードには、説明、在庫番号、価格などの情報が含まれます。当社の販売記録には、説明、在庫番号、価格も含まれています。説明と在庫番号は冗長であるため、削除する必要があります。これは悪いデザインでした。ただし、価格は両方の場所に含まれている必要があります。現在の価格と特定の販売時の価格には大きな違いがあります。その販売は何年も前だったかもしれません。それ以来、価格は十数回変更された可能性があります。

一般に、あなたが説明するようなアプリケーションでは、電話番号を履歴テーブルに入れて、それで完了します。「電話番号履歴」テーブルを用意し、その時点で該当する電話番号レコードにリンクしても、得られるものはほとんどありません。レコードごとに数バイト節約できるかもしれませんが、複雑さが増します。ただし、関連するフィールドがいくつかある場合は、ストーリーが変わります。たとえば、ここで例を挙げてアイデアを出している場合、あなたは健康保険会社であり、州法や地域で利用可能な医師などが異なるため、補償範囲は場所によって異なります。顧客が移動したときにポリシーを書き直す必要があるため、電話番号は他の多くのデータアイテムに関連付けられている可能性があるため、すべてを1つのテーブルにまとめて、適切なレコードにリンクする必要があります。

于 2009-08-18T17:00:53.280 に答える
1

あなたの質問は非常に典型的な設計のジレンマです。たとえば、通常の形式のデータベースがあり、次のテーブルがある場合：販売、マネージャー（販売者）、および地域（マネージャーが作業している場所）。「地域ごとにグループ化された年間売上高」のようなレポートを作成し、マネージャーとの販売および地域のマネージャーとの販売に参加します。しかし、マネージャーの1人がその年の間に別のオフィスに転居する場合、あなたのレポートには誤ったデータが表示されるようですよね？

3つの解決策は何ですか

1）場合によっては、開発者とアナリストが次のように判断します。データはあまり正確ではありませんが、今のところは問題ありません。通常の形式を維持し、データを複製しないようにします。このソリューションはそれほど複雑ではありません。この場合、CallersテーブルとCallHistoryテーブルを通常の形式で作成できます。つまり、電話番号はCallersテーブルにのみ存在します。

2）履歴の変更を失わないようにする必要があります。また、レポートとクエリを非常に高速にする必要があります（データベースのサイズを犠牲にして）。この場合、人々はすべてのフィールドを複製することにします。たとえば、電話番号、発信者名、住所などを含むCallHistoryテーブルを作成できます。これは、これらの各フィールドが将来変更される可能性があるためです。もちろん、Calleeテーブルを作成することもできます（おそらく別の目的で必要になります）が、CallHistoryによって参照される場合と、そうでない場合があります。一部のレコードをCalleeから削除する必要があるが、それらをCallHistoryに入れたいと考えているとします。これは、開発者がデータの参照整合性に違反する可能性があると考える場合が多く、CallHistoryテーブルから外部キーを作成しないでください。そして、これは合理的です。なぜなら、外部キーがなければ、

3）アプローチ私はもっと好きですが、実装の観点からは最も複雑です。CallHistoryテーブルはCalleeHistoryテーブルを参照する必要があります。CalleeHistoryテーブルには、Calleeテーブルが持つすべてのファイルが含まれますが、CalleeID + DateModified（DateModifiedの代わりに開発者がModificationVersionNumberを使用する場合もあります）などの代理キーもあります。CallHistoryには、CalleeID+DateModifiedを参照する代理外部キーがあります。この場合、データは正規化されており（つまり、電話番号は別のテーブルで重複していません）、履歴の変更も失われていません。

私が言った限りでは、実装の複雑さ、データベースのパフォーマンス、データベースのサイズ、データの整合性、およびシステムの機能要件の間には、しばしばトレードオフがあります。ジュニア開発者の場合、考えられるすべての解決策を念頭に置くのは良いことですが、おそらく、StackOverflowの誰よりもシステムと要件について知っているシニア開発者の話を聞く必要があります。

ps

他のアプローチについて知りたい場合は、ゆっくりと変化するディメンションについて読んでください。たとえば、http：//en.wikipedia.org/wiki/Slowly_changing_dimension

于 2009-08-17T07:50:46.143 に答える