【設計】RDBの基本思想（ソートが苦手）、大きなデータをソートしたい場合

RDB（リレーショナルデータベース）の基本思想

リレーショナルデータモデルには以下の思想になっています。

• データの重複がない。
• 実在する要素しかない。（NULLがない）
• 要素に順序(ソート)がない。

RDBMS（リレーショナルデータベース管理システム）では？

重複も、NULLもソートもあります。そう言う意味でRDBの思想だけでは多種多様なデータを管理することが難しいので「RDB」よりも仕様が拡張されているのです。

注意点

RDBMSでRDBにないものも扱えるようになりましたが、基本的にはRDBにないものを扱うことは苦手としています。

なので、「データの重複」、「NULLの存在」、「ソート処理」などはデータベースを扱う上ではボトルネックになりやすいので開発者はより意識して設計を行う必要があります。

リレーショナルモデルの性質

RDBの元となっている考え方として「リレーショナルモデル」があります。

• 重複がない。
• 実在する要素しかない(NULLがない）
• 要素に順序がない。

ただ、「RDBMS（リレーショナルデータベース管理システム）」には重複も、NULLもソートもあります。これはRDBMSは実際に必要なデータを「リレーショナルモデル」だけで表現することは難しいので拡張されているのです。

ただ、流行り拡張されたとはいえ、「リレーショナルモデル」にない世界の概念を扱うことは基本的に苦手でパフォーマンスのボトルネックにもなりやすいのです。

大きなデータをソートしたい場合の設計方法

RDBはソートが苦手なので、RDBMSの機能を使わずにソートすることが望ましいです。

もし、ソートがボトルネックになっていた場合は改善するにはアプリケーションの影響が大きく後から修正するのが大変です。

アプリ側でソート

最近は、クライアントの環境がリッチな環境になってきているので有効な手法の一つです。

メリット

• RDBの負荷を下げることができる。
• 表示に合わせて複雑なソートや、同じデータに対してリアルタイムでソートを切り替えたりできる。

デメリット

データ一覧をアプリ側に全て渡す必要がありデータサイズが大きすぎると通信がボトルネックとなる可能性がある。

ソート済みの結果をキャッシュして利用

ソート処理が決まっており、結果が変更されにくいデータ（例えば、郵便番号や市区町村の住所など）に関してはキャッシュが有効。

デメリット

• 更新頻度が高いデータの場合は使えない。
• アーキテクチャの複雑性が高まる。

NoSQLを利用してソート

近年ではこの方法が一般的になりつつあります。

RDBMSだけの構成の方がシンプルですが、やはりソート処理は苦手なのでRDBの苦手な部分はNoSQLなどの得意なサービスなどに委託することなども昨今は選択肢の一つになりつつあります。

Redisなどが活用されることが多いです。