はじめに
ToDoアプリやタスク管理ツールを作っていると、「あれ、このレコードたちの順序ってどうやってDBで管理するのが正解？」ってなることありませんか？
小規模ならなんとなくで済ませがちですが、ユーザーが並び替え機能を多用し始めると「思ったより運用がしんどいぞ？」となることも多いです。
今回は「順序付きリストをどうDB設計するか？」というテーマで、代表的な3パターンをサクッとまとめておきます。
一通りメリデメや使い所も添えてみたので、悩んでる方の参考になればうれしいです。
並び替えのアプローチの代表例
1. 序数（整数インデックス）方式
最初に思いつくのがこの「順序番号（orderカラムとか）」を各レコードに持たせるパターンです。
例えばこんな感じ↓
| id | name | order |
|---|---|---|
| 1 | りんご | 1 |
| 2 | ゴリラ | 2 |
| 3 | らくだ | 3 |
順序の管理はシンプル。
1, 2, 3... のように番号を振って、ORDER BY order で好きな順に出せます。
ただし並び替えや挿入が頻繁だと、途中に1件追加したい時とか、前後のレコードを全部更新する必要が出てきます。
タスクを「3番目から1番目」に持っていく、みたいな場合も同様です。
メリット
- 実装がシンプル
- SQL初心者でもわかりやすい
デメリット
- 並び替えや追加が多いと、更新件数がどんどん増える
- 大規模・高頻度な並び替え用途にはあまり向かない
2. float（分数インデックス、Fractional Indexing）方式
最近流行りのやつ。
sort_index カラムに float 値を入れて「並び順」を表現します。
例えば↓
| id | name | sort_index |
|---|---|---|
| 1 | りんご | 100.0 |
| 2 | ゴリラ | 200.0 |
| 3 | らくだ | 300.0 |
「ゴリラ」と「らくだ」の間に新しいアイテムを挿入したい場合、
(200.0 + 300.0) / 2 = 250.0 みたいに、中間値を計算して入れるだけ。
移動の場合も同じで、間に入れたい時はその間の値にするだけで済みます。
ドラッグ＆ドロップUIとの相性も良いです。
メリット
- 並び替え・挿入時に「1件だけ」更新で済む
- パフォーマンスが安定しやすい
- Trello や Notion などでもこの方式が使われている
デメリット
- 何度も間に挿入しまくると、小数点以下がどんどん細かくなりリインデックスが必要になる場合がある
- 実装がやや複雑になる
参考：Realtime Editing of Ordered Sequences | Figma Blog
3. Linked List（前後IDでつなぐ）方式
ちょっとマニアックだけど「prev_id」や「next_id」を持たせて、レコード同士をつなぐ方式もあります。
| id | name | prev_id |
|---|---|---|
| 1 | りんご | NULL |
| 2 | ゴリラ | 1 |
| 3 | らくだ | 2 |
データベース上で「実際にリスト構造を再現する」イメージです。
レコードの移動・削除は、前後のレコードの prev_id/next_id だけ更新すればOK。
（ただし、隣接関係の更新ロジックが必要で、SQLだけだとちょっと扱いづらい）
メリット
- 挿入・削除が隣接レコードだけの更新で済む
- 極端な場合にも対応しやすい
デメリット
- 実装がやや複雑、SQLだけでゴリゴリやるのは面倒
- 順序付きで全件取得したい場合は再帰 or N+1問題に注意
それぞれの使いどころ & ベストプラクティス
-
序数（整数）方式
シンプルな管理画面・レコード数が少ない or 並び替え頻度が低いケースにおすすめ。
「時々順序を変えたい」程度ならこれで十分。 -
float（分数/Fractional Indexing）方式
並び替え・挿入が多い、もしくはドラッグ＆ドロップUIを作りたい時は圧倒的にこっち。
TrelloやNotionの「スムーズな並び替え」体験を自作したいなら迷わずどうぞ。 -
Linked List方式
極端な並び替え・挿入・削除操作や、何らかの事情で順序情報以外にも「リスト的な構造」を活かしたい場合に。
（個人開発やお遊びプロジェクトで試してみるのもアリ）
まとめ
- 並び替えのDB設計、用途や規模によって選ぶ方式が変わります
- 小規模・簡単な用途なら「序数方式」
- ドラッグ＆ドロップや大規模リストなら「float（Fractional Indexing）方式」
- リスト構造そのものを活かしたい・チャレンジしてみたいなら「Linked List方式」
どれを選ぶにしても、「運用後にどうなるか？」をイメージして設計するのがコツです！
他にも「こんな方法あるよ」とか「運用で詰まった話」あればぜひコメントで教えてもらえるとうれしいです。
参考資料