はじめに
素人が推測してみただけの内容ですが、
投稿を扱うサービスには、参考にしていただける部分があるかも。
Twitterの設計にどうこう言いたいのではなく、「変更可能な文字列IDを扱う」場合の１事例と思っていただければ。
検索の対象は「ツイート当時のID」
X(Twitter)には「高度な検索」という機能があります。
文言やユーザーIDなどから検索できる機能です。
通常の検索窓からも使用できます。
| 高度な検索 |
|---|
 |
この機能を使用し、過去のツイートを検索してみましたが・・・
検索結果がありません。IDは正確です。
ふと思い当たり、昔のIDで検索すると・・・
表示されました！
「ツイート当時のIDで検索」する必要があるんですね。
なお、表示結果には「現在のID」が表示されています。
ここからわかるのは、以下です。
- 「ツイート」は「文字列ID」と紐づいて保存されている
- 「昔のID」と「今のID」を紐づける何かがある
「昔のID」と「今のID」を紐づける方法の詳細はわかりませんが、
例えば、next_idを記録しておくのは一つかもしれません。
ただ、芋づる式にidを追う必要があり、ユーザー体験だけでなく処理効率も悪いです。
現在のIDでも検索できる仕組み
「昔のIDを覚えてないといけない」仕組みは、ユーザー体験としてマイナスだと思います。
- 文字列IDの他に、内部的に数字IDが存在
- 文字列IDを数字IDにマッピングする
という仕組みにすると改善できそうです。
具体的には
- （擬似的に）文字列のIDを扱う
- 文字列IDのUPDATEに対応
上記の機能を持ちながら、下記の機能が追加されます。
- 現在のIDでの全履歴検索
- 古いIDでの全履歴検索
（テーブル名へのツッコミはご容赦を）
おわりに
改めてにはなりますが、本記事の内容はあくまで推測です。
Twitterの設計にどうこう言いたいのではなく、「変更可能な文字列IDを扱う」場合の１事例として考察してみました。