5

作業指示書/チケットを追跡および処理するアプリケーションに取り組んでいます。各チケットは、MySQL の変更をカスケードする外部キーを介して、チケットを作成/所有するユーザーにリンクされます。ユーザーが何らかの理由でアカウントを削除したとしても、チケットと基本情報を記録しておきたいと思うことは明らかです。

これを実現する最初の方法は、ユーザーがアクティブか非アクティブか、つまり削除されたかどうかを示す列をユーザー テーブルに作成することです。そうすれば、アカウントを閉鎖/削除すると、この値が反転するだけで、アプリにアクセスできなくなります。

私が持っていたもう1つのアイデアは、アカウントが削除されたときに、ユーザーレコードを削除されたユーザーテーブルに移動することでした. この方法では、users テーブルのパフォーマンスを最高の状態に保つことができます。これは、テーブルが大きくなると非常に大きな問題になる可能性がありますが、レコードを移動するための追加のクエリが追加されます。

明らかにこれの一部は好みかもしれませんが、私はパフォーマンスの側面に興味があります. 基本的に問題は、選択クエリと挿入クエリを比較する方法と、挿入クエリ (削除されたユーザー テーブルへのレコードの移動) をミックスに追加することにより、全体的なパフォーマンスがどの時点で向上するかということです。

4

2 に答える 2

11

users テーブルに、ユーザーがアクティブか非アクティブか、つまり削除されたかどうかを示す列があります。

良い。

私が持っていたもう1つのアイデアは、ユーザーレコードを削除されたユーザーテーブルに移動することでした

悪い。これで、ユーザーからチケットへの結合と元ユーザーからチケットへの結合の 2 つの結合ができました。これは不必要な複雑さです。

大きくなると大変なことになりそうですが、

「大規模」とは何百万ものユーザーを意味するのであれば、その通りです。ただし、「大」とは数千人のユーザーを意味する場合、大きな違いを測定することはできません。

と。将来的に測定可能な速度低下が実際に発生する場合は、「マテリアライズド ビュー」などを使用して、「アクティブな」ユーザーのサブセット ビュー/テーブルを自動的に作成できます。

明らかに、これの一部は好みになる可能性があります。

あまり。ユーザーの非アクティブ化 (削除ではなく) には多くの利点があり、実際の欠点はありません。

さまざまなレベルのアクティビティがあります。セキュリティ ロックアウト (ただし、無効化されていません)、一時的に無効化、別のユーザーに委任されています。ステータス変化が多い。削除の理由はいくつかあります。「別のテーブルに移動」する理由はありません。

選択クエリは挿入クエリとどのように比較されますか? また、挿入クエリ (削除されたユーザー テーブルへのレコードの移動) をミックスに追加すると、全体的なパフォーマンスはどの時点で向上しますか?

テーブル、インデックス、サーバー、およびトランザクションの組み合わせについてこれを測定できるのはあなただけです。一般的な答えはありません。

于 2011-12-21T18:26:55.537 に答える
1

私の意見では、ユーザーを削除済みまたは削除済みとしてマークすることは、より良いアプローチです。新しいテーブルを使用する2番目の方法では、usersテーブルを参照するすべてのテーブルに変更が加えられます。「削除されたユーザーテーブル」への新しい外部キーが必要です。これにより、このテーブルの選択行に対するすべてのクエリが変更されます。

あなたが書いたように、アプリはチケットに関するものであり、論理的にはほとんどのクエリはチケットの選択と編集に関するものです。したがって、このテーブルに影響があります。ユーザーについて大きな質問をすることはないと思います。

「ユーザー」テーブルの最適化と「チケット」テーブルのより複雑なクエリの作成は、見返りがありません。

于 2011-12-21T18:39:14.020 に答える