【データベース】「JSON型」について

JSON型

EAVの代替手段として近年登場してきました。

MySQLであれば、5.7.8以降で使えるようになった新たなデータ型です。基本的にはカラムの汎用性を高めて変更に強くし開発効率を上げることができます。

ただ、EAVと同じようにデメリットをあまり解消できてない部分があるので、その辺も慎重に考慮しなければならないでしょう。

MySQLの他にも、PostgreSQL、SQLServer、Teradata、IBM DB2などがJSON型をサポートするようになりました。

メリット

• JSONをそのまま格納すれば良いので開発工数は下がる。
• 変化に柔軟な設計ができる。
• TEXT型にJSONを入れていた場合に比べたら難易度が下がる。

デメリット

• ORMが使えない。
• SQLの難易度が上がる。

ただし、PHPのフレームワークである「Laravel」の「Eloquent」はJSONデータ型に対応しているのでLaravelを使っている場合はあまりデメリットがないかもしれません。

ユースケース

以下のようなケースの場合にJSON型を使うのが良いでしょう。具体的にはパソコンの周辺機器の詳細情報などを保存する場合などや、TwitterのAPIの結果（WebAPIの戻り値）を保存したい場合。

• 一度保存した情報に対してアップデートをする必要がほとんどない場合
• 取り出すときは、JSON丸ごと取得するケース
• 例えば、TwitterのWebAPIは頻繁に予告なくAPIの構造を変更するので保存する場合はJSON型が適しているかもしれません。
• ユーザーが任意の値を値を設定したい仕様の場合（例えば、自作CMSなどでユーザーが独自にカラムを作ることができる機能があるなど）
• あまりデータ件数が多過ぎないこと。（多く共数千件程度が目安）

データ件数が多すぎるとJSONデータ型は少しデータ量が多いので通信量が多くなってしまいます。昨今はリクエストの通信量に上限があるサービスやプロトコルも多いのでJSONデータ型を使う場合は考慮ポイントになり得ます。

また、開発途上のサービスであって今後の方向性が読めない場合などでもまずは一旦は導入という形で採用しても良いかもしれません。

まあ、ほとんどのケースが上記の条件には該当しないので基本的にはJSON型はほぼ使うケースはないでしょう。

ドキュメントDBとの違い

MySQLにはドキュメントDBのようにスケーラビリティがあるわけではない。ドキュメントDBと似た機能ですが、ドキュメントDBにはそういう意味では分類するものではないでしょう。