このシナリオでは、どのDB接合アプローチがより効率的ですか？

Question

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

簡略化のため、OrderとInvoiceの2つのテーブルがあり、各請求書には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では、データベース内の各テーブルに対して追加の削除テーブルを作成する必要がなくなり、システムの成熟度が高まり、クエリが遅くなるため、

どれが全体的により効率的になるのでしょうか、それともこれにアプローチする方が良いでしょうか？

Answer 1

どのくらい保持する必要があり、どのように使用するかによって異なります。請求書とオーダーのすべての詳細（NumberOfStuffOrdered、Taxなど）を記録する必要がある場合は、特定の削除テーブルが必要です。一行が存在していたという事実（Id、タイプ、Date [Deleted]、Reason）を今すぐ記録する必要がある場合は、「それは依存する」サイクルに戻ります。

実際にデータを使用する人がいない場合、ある日IRS監査の可能性があるという事実だけが必要な場合は、1つのテーブルで十分です。 （類推は、70年前のフォームの箱で満たされた倉庫ですが、時間がかかりますが、最終的に見つけることになります）。しかし、定期的にこのデータにアクセスしてレポートを実行する場合は、データマイニングまたはそれが何であっても、正規化されたスタースキーマなどのテーブルを設計するのに最適です。

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