0

ソフト削除を回避するために、ごみ箱データベースを作成しています。メインデータベースはそれに接続します。これは2つの可能なジャンクションアプローチの例です、そして私はどちらがより効率的であるかについてのいくつかの入力を望んでいましたか？

Order簡単にするために、2つのテーブルがあるとしましょうInvoice（そして各請求書には1つの注文しかありません）。

Order
-----
OrderId
InvoiceId
Description
Date
NumberOfStuffOrdered

Invoice
-------
InvoiceId
Description
Price
Tax
Shipping

これらのテーブルをごみ箱に接続するために、どのアプローチを取るべきかわかりませんでした。

アプローチ1：

DeletedOrder
------------
DeletedOrderId
OrderId
RecycleBinId
Date
Reason

DeletedInvoice
--------------
DeletedInvoiceId
InvoiceId
RecycleBinId
Date
Reason

アプローチ2：

DeletedRecords
--------------
DeletedRecordsId
RecordPrimaryKeyId
RecycleBinId
RecordType
Date
Reason

アプローチ1はデータベース内でより多くの表スペースを使用しますが、表あたりの行数が少なくなり、システムが成熟するにつれてクエリ時間が短縮されます。アプローチ2は、データベース内のテーブルごとに追加の削除済みテーブルを作成する必要があることを統合しますが、システムが成熟するにつれて、サイズが大きくなり、クエリが遅くなります。

どちらが全体的に効率的ですか、それともこれにアプローチするためのより良い方法がありますか？

4

1 に答える 1

1

それはあなたがどれだけ保持する必要があるか、そしてあなたがそれをどのように使うかによります。請求書と注文のすべての詳細（NumberOfStuffOrdered、Taxなど）を記録する必要がある場合は、特定の削除テーブルが必要です。行がかつて存在したという事実（現在の行：Id、type、Date [Deleted]、Reason）を記録するだけでよい場合は、「状況によって異なります」に戻ります。

誰も実際にデータを使用する予定がなく、いつかIRS監査の機会にデータが存在したという事実が必要な場合は、単一のテーブルで十分です。（例えは、70年前にさかのぼるフォームのボックスで満たされた倉庫です。時間がかかりますが、最終的には見つかります。）ただし、定期的にこのデータにアクセスしてレポートを実行する場合は、データマイニングを実行してください。 、またはその上にあるものなら何でも、それらのプロセスをサポートするテーブルを設計するのが最善です-正規化された、スタースキーマ、または有用なものは何でも。

一般に、良好なパフォーマンスが重要でない限り、頻繁なクエリをサポートするいくつかのインデックスを持つ大きなテーブルで十分だと思います。

于 2012-03-29T20:19:27.477 に答える