EAVにMySql 5.7 JSON列を使用する

私はeコマース製品を開発しており、すべての機能を実装できたため、ユーザーが製品の追加属性を作成できるようになりました。現在、私には2つのオプションがあります。

EAV

EAVは主に眉をひそめていますが、Magentoで動作するようです。しかし、すべての頭痛を調査した後、それを使用するのには少し気が進まなくなります

MySql 5.7でJSON列を使用する

これはかなり新しいものであり、他のどこにも実装されていないので、JSON属性を照会した結果として全テーブルスキャンを実行するのは大変です。しかし、このMySql 5.7 JSONを読んだ後、彼らはJSONの使用を推奨しているようです。そして、この実用的なMySqlスキーマアドバイスのようなものを実装するよりも、それほど面倒ではありません。

私の質問は、NoSQLは私にとってオプションではないので、属性を格納するJSON列の方法を使用することに偏っていますが、EAVテーブルを使用するよりも深刻な欠点があります。

EAVもJSON列の選択も悪いアプローチではありませんが、データベースに格納されたデータをどのように処理するかによって、どちらが適切かは異なります。

ユーザー定義の属性を持つ製品を用意し、製品全体を読みたい場合は、JSONの方法でパフォーマンスが向上します。製品全体が1つのテーブル内に配置されるため、データベースから取得したJSONを単純にデコードし、フロントエンドで自由に処理できます。

ただし、製品全体を読むだけでなく、将来の洞察により、特定の属性（色としましょう）を持つ製品をフィルターで除外する機能を導入する場合、EAVアプローチを使用すると、この操作のパフォーマンスが向上します。属性名が検索対象の商品と直接一致する商品を除外できます。

SELECT
    pa.ProductId
FROM
    product_attributes pa
WHERE
    pa.`Name` = "color"

JSON列でこの機能を使用している場合、JSON属性モデルを通過すると、直接の文字列比較よりも多くのリソースを消費します。

モバイルアプリケーション用のREST APIバックエンドの開発者として、私が頻繁に取り組んでいる例は、モバイルクライアント内の通知センターを通じて受信したプッシュ通知の概要をユーザーに提供することです。

データに対して頻繁に大量のクエリを実行する予定はないので、JSON列は完全に問題ありません。ユーザーがクエリを実行するときに、さまざまな形式で存在するデータをユーザーに提供したいだけなので、データベースからデータを取り出してユーザーにダンプします。REST APIの表面はJSONであるため、さらに優れています。EAVモデルの場合に必要となるような追加のフォーマットを行う必要もありません。