JSON型 (DB)
>#WIP
stringを突っ込む感じ
ただし、validなJSONでないとerrorになる
内部で最適化されるので速い
これは文字列型にJSONを入れたものからアクセスするより速いという意味
JSONを扱いやすいように関数が提供されている
e.g. 中身を検索しやすい、中身を更新しやすい
indexが使えない
ただし、特定のfieldだけindexをはる方法はあるらしい
型の指定としては、以下のように
json を指定するだけsqlCREATE TABLE `book` (
...
`tags` json DEFAULT NULL,
) ENGINE=InnoDB;つまり、クソ雑だということ
fieldの型は指定できないし、もちろん参照をはることもできない
データ的には
tags.item.id が、 item table を見てたとしても、そこに関連性をもたせることはできないOR型をtable上でどう表現するかの問題を考えた上での、最終手段という感じだろう
>JSONは絶対に必要ではない限り利用はおすすめしません。MySQLでドキュメント指向のNoSQLデータベースを模倣できるかもしれませんが、SQLの多くの利点が損なわれてしまうでしょう。本物のNoSQLシステムに切り替えた方がまだましです。ref
>@t_wada: 列が実行時まで決まらず、有限のバリエーションに収まらないとき（例: エンドユーザーが作成するアンケートフォーム等）で、かつそれを EAV アンチパターンで解決したくないときに使います（バリエーションがそこまで多くないなら STI や CTI などのパターンで仕留めます）
そらそう
そのJSON型を使うcolumnの中身は、常に同じ構造とは限らない
それはそう。
常に同じ構造に出来るなら正規化できるはず
構造が不定なものを無理やり一緒くたにしたいからJSON型を使うことになるはず
ということは、それを取得したアプリケーション側でかなりvalidaitonしないといけない
parseして構造を見ながら特定の型に変換していかないといけない
Tagged Unionしてるならやりやすい
が、insert時にTagged Union必須です、という制約は付けられないはず
もっと悪いケースだと、そもそもアプリケーションで予測できない構造というのもありうる？
まじで自由に何でも入力できるフォームとかを作るとありそう
Protocol Buffersと併用すると良いというtips
IDLで書いてJSONを生成する
deserializer,serializerも生成される
破壊的変更に対して強い
>まず、 Protobuf のシリアライザとデシリアライザは、未知のフィールドを無視し、欠けているフィールドには型に合わせてゼロ値を補います。したがって、新しいコードで古いデータを読む場合や、逆に古いコードで新しいデータを読む場合（例えば、フロントエンドがバックエンドより後にデプロイされた場合）でも、クラッシュすることなく動作します。
>
> また、使わなくなったフィールドを予約しておくことで、同じ名前のデータが再利用されるのを防ぐことも可能です。