"コメントをもっと読み込む"ボタン - >データベースの変更によって重複が読み込まれないようにする

Question

ユーザーがコメントを読み書きできるアプリケーションをコーディングしています。

コメントの数が一定の制限を超えると、「コメントをもっと読み込む」ボタンが表示され、読み込まれたコメントのオフセットが保存されます。

ユーザが自分のコメントを書き込んだり削除したりして、重複がロードされずコメントが残っていないときはいつでも、このオフセットを更新します。

しかし、他のユーザーがコメントを追加/削除したためにデータベースが変更された場合は忘れました。

オフセット方法が信頼できないようですので、最後のコメントのIDを保存し、これを何らかの「オフセット」として使用することでこの問題を解決する方法はありますか？私のクエリ内の句が似ている

ザ・：

WHERE x = ? ORDER BY y = ?（いずれもXもyがIDあり、yは一意ではない）

Answer 1

あなたはタイムスタンプ列または可能性も主キーを使用してこれを行うことができますそれはあなたがそれをどのように設定したかによって決まります。主キーがAUTO_INCREMENTの整数である場合の使用例を次に示します。そのテーブル定義で

CREATE TABLE `comments` (
    `comment_id` int NOT NULL AUTO_INCREMENT, 
    `thread_id` int NOT NULL, 
    `comment` text, 
    PRIMARY KEY (`comment_id`), 
    FOREIGN KEY (`thread_id`) REFERENCES `threads` (`thread_id`) 
); 

、あなたはAUTO_INCREMENTint主キーを持っています。 threadsテーブルへの外部キーであるthread_idもあります。最後に、commentにコメントがあります。

あなたが最初にあなたが以下にしてくださいいくつかのスレッドのためにページをロードする場合：

SELECT comment_id, comment 
FROM comments 
WHERE thread_id = 123 
ORDER BY comment_id 
LIMIT 10; 

これはあなたの指定されたスレッドのための彼らのint PK順10件のコメント（この場合は123）を選択したいこと。今、あなたがこれを表示すると、どういうわけか最大のcomment_idを保存する必要があります。この場合、それは10です。次に、「Load more comments」ボタンをクリックすると、この最大サイズのcomment_idがサーバーに渡されます。サーバーは現在、次のコマンドを実行します：

SELECT comment_id, comment 
FROM comments 
WHERE thread_id = 123 AND comment_id > 10 -- 10 is the value you passed in as your largest previously loaded comment_id 
ORDER BY comment_id 
LIMIT 10; 

は、今あなたがコメントのどれもが、おそらく、あなたの前に表示されたコメントの重複になることはできませんことを知っている10件の以上のコメントのセットを持って、あなたは任意のコメントをスキップすることはありませんそれらは常に昇順でintのキーで注文されるためです。

最初のコメントの読み込みに使用したクエリを参照すると、追加のコメントを読み込むためのものとほぼ同じであることがわかります。したがって、実際には両方の。最初にコメントを読み込むときは、comment_idとして0を渡すだけです。

timestampカラムを使用して同じことをすることもできます。このように動作する主キーがなくても、このように動作するように変更する必要はありません。結果をtimestamp列で並べ替え、最後に読み込まれたコメントのtimestampを「コメントをもっと読み込む」機能に渡します。同時に投稿されたコメントをスキップしないようにするには、timestampを6桁の分数秒精度で使用します。 TIMESTAMP(6)としてtimestamp列を作成します。あなたのタイムスタンプは2014-09-08 17:51:04.123456のように記録されます。ここで、秒の後の最後の6桁は秒の小数です。これほど精度が高いため、同時に正確にコメントを記録することはほとんどありません。

もちろん、同じ正確なタイムスタンプで2つ以上のコメントを記録することはできますが、そうは思われません。これにより、AUTO_INCREMENTintが少し改善されました。最終的な選択肢の1つは、時間ベースのUUIDを使用することです。これは、同じマイクロ秒で発生したときに値をわずかに調整して一意性を保証するメカニズムを含むためです。彼らはまだ時間が経ちました。この問題は、MySQLがUUIDを非常にうまくサポートしていないことが原因です。