minimizedする
JSONでは改行不要、スペース不要の為、その辺りを削ると結構サイズ減ります。これを圧縮と呼ぶ場合あります。
ファイルをzip圧縮する
一応ベタな方法なので、まあまあそのまま。
カラム指向の表現形式という事にして、重複記述を削るような事する
SDTMは正規化という概念に反逆を起こしていて無駄にデータが大きい訳ですが、多分カラム指向とかぶっこめば、可読性とかだいぶ気にしなくなり、削っていけるのでは。
カラム指向のDBは、内部的にはこんな感じでデータを持っています。
| ID | ID_AETERM |
| 1 | @1 |
| 2 | @2 |
| 3 | @3 |
| 4 | @4 |
| 5 | @5 |
| ID_AETERM | AETERM |
| @1 | 発熱 |
| @2 | ALT上昇 |
| @3 | 心不全 |
| @4 | : |
| @5 | : |
ID_AETERMが外部キーのようなもので、全部、入力値は別途管理されるようなイメージです。
Oracleでも、可変長文字列の場合、実のところこんな感じです。可変長文字列で定義すると、テーブルにはポインタが置かれ、別テーブルで管理されている文字列格納場所に内容が書かれ、ポインタ経由して文字列取ってきます。それの徹底みたいなのがカラム指向のDBです。
このAETERMの場合、実はカラム指向DBだとイマイチ恩恵に預かれないのですが（むしろ遅い・容量が大きい）、以下のようなAEOUTのケースだとだいぶ違います。
| ID | ID_AEOUT |
| 1 | @1 |
| 2 | @2 |
| 3 | @1 |
| 4 | @1 |
| 5 | @1 |
| ID_AEOUT | AEOUT |
| @1 | 回復 |
| @2 | 死亡 |
データ容量が小さくなりそうな気がするかと思います。また、例えば回復の文字が含まれるとかを検索する場合、後ろのテーブルで含まれる@～を検出して該当する@1がどのレコードに該当するかを検索すればいいだけなので、レコードが増えれば増えるほど有利になるとかもわかるかと思います。
なお、カラム指向DBだとこの指向を意識したクエリを作る必要が出てくるのも分かるとは思います。
余談：通信過程で圧縮を効かせる
データ転送なんで、HTTPのところで圧縮効かせます。当局の電子申請システムに、名前ど忘れしましたがツール使われてたりしましたが、あれはHTTP通信ではないはず。そういうレベルで実装する感じです。
モダンブラウザではほぼ圧縮に対応しているので、特に気にせず使ってたりするでしょうね。
en.wikipedia.org
HTTP/3が2022年にRFC化したようで、高校の同級生がやってるのでちょくちょくチェックはしているのですがあまりにレイヤーが違うので見てるだけでした。が、まあ、今後、電子申請のポート開放だとかの必要性が、無くなっていくはず（とか言いながら何十年も維持されそう）
HTTPが全てを飲み込む（前編）～HTTPの2層構造と、HTTP Semanticsとは何か？ － Publickey
ただし、このHTTP/3、現在最新版のブラウザだと既に対応・利用もだいぶ普及しており、動画とか見る時には使われているかもしれません。
gigazine.net
なので、結構この辺り、最新バージョンへアップデートとかを検討された方がいいシステムが沢山出てくるような気がします。
