10

だから私はユーザーのお気に入りのテーブルを持っています。数百万行あります。

id現在、 (pk)userIdとの3 つの列しかありませんsomeFkRef。userIdユーザーのお気に入りをすばやく選択できるようにするためのインデックスがあります。

現在、これらidは事実上単なる挿入順序で並べられています。ユーザーがお気に入りを並べ替える機会をユーザーに提供したいと考えています。これはおそらく、ある種のドラッグ アンド ドロップ操作を介して行われます。

これに対する私の最初の (そして単純だと思う) アプローチは、単にorder列と複合インデックスをuserId,に追加することorderです。ただし、リフレクションでは、ユーザーがアイテムをリスト上である程度移動すると、アイテムの開始位置と終了位置の間のすべての中間行でorder列を再計算する必要があるため、インデックスも再計算されます。

これは (ほとんどの場合) 悪いことです。

どれだけ悪いかを正確に定量化するために何年も費やす前に、上記で説明した種類の操作でより安価に操作できる、より優れたテーブルベースの表現があるかどうか疑問に思っています。

4

3 に答える 3

7

ドラッグ アンド ドロップ操作の場合は、より良い方法が優先されます。並べ替え順と同じように、1、2、3 などの優先順位から始めます。

しかし、ユーザーは項目 5 を 1 と 2 の間で移動したいと考えています。値を 1.5 にします。他の値を変更する必要はありません。残りはインデックスの更新によって処理されます。

これが機能するには、優先度を浮動小数点数として格納する必要があります。それは問題かもしれません。また、十分な数の変更が行われると、浮動小数点の限界が押し上げられる可能性があります。そのため、ユーザーが最後の要素を取得して最初の 2 つの要素の間に挿入しようとすると、数十回程度は回避できます。

これは、1 人 (バッチの場合はすべてのユーザー) の番号を 1 から定期的に再割り当てするプロセスで修正できます。

于 2013-02-27T17:21:44.840 に答える
3

複数のユーザー間で someFkRef を操作できるようにする必要がない場合 (たとえば、何かに関心のあるユーザーのリストを取得する場合)、someFkRef (refA、refB) の順序付きリストを使用して、ユーザーごとに 1 つのレコードのみを持つことができます。

しかし、これは一種の非正規化であり、いくつかの欠点があるため、実際にはニーズに依存します (そして、将来のニーズ、それが問題の原因です)。

于 2013-02-27T17:21:24.857 に答える
1

ID フィールドへの依存参照が何であるかはわかりませんが、それを上書きすることを考えたことはありますか? SET IDENTITY INSERT = ON、またはそのようなものがあると思います。

これを提案するのは奇妙なことだと思いますが、あなたがやろうとしていることを考えると、それは理にかなっていて、オーバーヘッドを最小限に抑えることができます.

于 2013-02-27T17:26:11.720 に答える