データベースの効率について質問があります。
ここに私のテーブルに関するいくつかの情報があります:
- 約 500 ～ 1000 レコードのテーブル - レコードは毎日追加および削除されます。- 通常、毎日ほぼ同じ量が追加および削除されます (アクティブなレコードのサイズは同じままです)
さて、私の質問は...レコードを削除するとき... (A) レコードを削除して新しいテーブルに移動する必要がありますか?
または、...私（B）は「アクティブ」列を持ち、アクティブでなくなったときにレコードを0に設定する必要があります。
私が B の使用をためらう理由は、私のサイトが、ユーザーがこの 500 ～ 1000 レコードのテーブルをその場で (ajax を使用して) フィルタリング/ソートできることに基づいているためです。可能です..（より多くのレコードを持つテーブルはフィルタリングが遅くなると思います）...そして私はmySQL InnoDBを使用しています。
どんな入力も素晴らしいでしょう、ありがとう
アンドリュー
〜 1000 レコードは非常に少ない数です。
レコードを削除して後で再度追加できる場合は、「アクティブ」インジケーターを使用するのが理にかなっています。
現実的には、これは DB の効率に関する問題ではなく、ネットワークの遅延と、ネットワーク経由で送信するデータの量に関する問題です。MySQL に関する限り、1000 行または 100k 行は非常に高速であるため、問題はありません。
ただし、これらの行に相当量のデータがあり、フィルタリングのために AJAX を介してすべてのデータをクライアントに送信している場合、ネットワーク遅延がボトルネックになります。行ごとに少数のバイト (たとえば 20) を送信していて、テーブルの長さが約 1000 レコードのままである場合、大きな問題ではありません。
一方、テーブルが (非アクティブなレコードで) たとえば 20k 行に成長した場合、20k ではなく 400k を送信していることになります。ユーザーは気付くでしょう。レコードが大きい場合、テーブルが大きくなるにつれて問題はより深刻になります。
サーバー側でフィルタリングを行う必要があります。Ajax 経由で送信するのに 1 秒か 2 秒を費やす前に、MySQL がテーブルのフィルタリングに 2 ミリ秒費やすようにします。
フィルタリング/ソートの対象と、テーブルのインデックス方法によって異なります。
珍しいことではない 3 番目のオプションとして、レコードを非アクティブ化し (B) (オプションでタイムスタンプ付き)、定期的に別のテーブルにアーカイブする (A) (まとめて、またはタイムスタンプの経過時間に基づいて) ハイブリッド アプローチを使用できます。 .
現実的には、テーブルが 1000 行のオーダーである場合、(他の要因のスケーラビリティが既知であると仮定して) あまり気にする必要はありません。
将来の目的のために記録を保持する必要がある場合は、非アクティブ ビットを設定します。
SELECTテーブルに主キーがある限り、レコードを ing するときのパフォーマンスは優れているはずです。
また、クライアント側でフィルタリング/ソートを行う場合、レコードを取得する必要があるのは 1 回だけです。