JSONもよいがリレーショナルがよいところもある
JSONは柔軟性が高く、データ連携において、特にフロントエンドの開発に有用と言えそうです。ただ、JSONがすべてにおいて最適かというとどうでしょうか？
スキーマレスであるため、データを扱うにはドキュメントのデータ構造を知ったうえで目的のデータまで辿ることになります。データの分析や集計には扱いづらいところです。
また、マスターが存在しないので、整合性を保つ必要があるデータの更新／追加／削除は、そのデータが含まれるすべてのドキュメントに対して行わなければなりません。これもアプリケーション側で担保することになります。
勘の良い読者のみなさまは既にお気づきかもしれませんが、これらは、リレーショナルの得意分野です。ここではJSONと比較しながらリレーショナルのメリットを改めて確認してみます。
まずは一覧として取り扱いやすい点です。厨房で回鍋肉が出来上がってきたとします。その際にどこのテーブルへ運べばよいか分かりやすいのはどちらでしょうか。注文伝票の場合は非常にたくさんの伝票をめくって読んでいかないと確認できないですね、テーブルとお客さまが多くなると担当者は大変です。一方で行と列で構成される表形式のリレーショナルであれば、メニュー列の回鍋肉を探せばどのテーブルかすぐにたどり着けます。
それに、これまでの売上データから販促のために何かしら分析したいと言うニーズも多くあるでしょう。その際、注文伝票1日分だけならまだしも、1カ月、1年といった期間で注文データを振り返りたいとしたらどうでしょうか？ 多数の伝票をパラパラめくることは大変手間がかかる作業です。大半のケースでは表形式ソフトウェアに転記して（リレーショナルに一度フォーマットを変換して）利用しているのではないかと思います。
そのうえ、リレーショナルで使われるSQLは、データの一覧だけでなく結合やいろいろな条件をつけての参照や、集計、分析の記述を行うことができます。そのため、集計や分析を目的にした場合にはリレーショナルに軍配が上がるのではないでしょうか。
次に正規化と制約を活用できる点です。リレーショナルで格納する場合、大半のケースで注文明細表とメニュー・マスター表、従業員マスター表といったようにデータを正規化して格納します。正規化によりデータ量を削減することができますし、ロジックをアプリケーションに反映させやすくなります。
例えばメニューの改名やメニューに無い料理を受けた場合を想定しましょう。リレーショナルであれば、改名はメニュー・マスター表のみの更新で完了します。また、メニューにない品目の注文は、メニュー・マスター表との参照制約を利用してエラーを返すといった実装が容易です。しかし、JSONにおいては関連するアプリケーション側のロジックでこれらを担保する必要があります。その分、リレーショナルと比べると、コードレビューやテスト工程が多くなりますね。
つまり、データをJSONで管理するかリレーショナルで管理するかはそれぞれ一長一短があるということです。ざっくり分けると、データ構造の柔軟性が求められるデータはJSON、整合性を求めるデータや複雑な分析や正規化が必要なデータはリレーショナル、とデータの利用目的に応じての選択が望ましいとなります。
しかし、データの活用となると、片側だけを利用するケースだけでなく両方を合わせて利用するという要望も出てきます。例えば、チェーン展開した中華料理屋さんで本部の人が各店舗の個別のメニューの売り上げを知りたいとなると、本部にあるリレーショナルの店舗マスターと各店舗のJSONの伝票データとの結合が求められます。両方のデータを取り出してアプリケーションで実装するか、結合が容易なSQLが利用できるようにJSONをリレーショナルに変更してリレーショナルに統一して操作することになりそうです。どちらにしても手間がかかります。
理想的には、JSONの利便性も、リレーショナルの一貫性、整合性も保持しながら、両方のデータの連携も容易に行いたいところです。そのようなことは可能なのでしょうか。
