Usando colunas JSON MySql 5.7 para EAV

Estou desenvolvendo um produto de comércio eletrônico, pude implementar todas as funcionalidades e deixo que os usuários criem atributos adicionais para um produto. Agora eu tenho duas opções.

EAV

O EAV é amplamente desaprovado, mas parece funcionar para o Magento. Mas depois de pesquisar todas as dores de cabeça, sinto-me um pouco relutante em usá-las

Use colunas JSON no MySql 5.7

Isso é bastante novo e eu não o vi sendo implementado em nenhum outro lugar e estou com receio de verificações de tabela completas como resultado da consulta dos atributos JSON. Mas, depois de ler este JSON do MySQL 5.7, eles parecem recomendar o uso do JSON. e seria menos cansativo do que implementar algo como este conselho prático do esquema MySql .

Minha pergunta é: embora eu seja inclinado a usar a maneira da coluna JSON de armazenar atributos, já que o NoSQL não é uma opção para mim, existem desvantagens mais severas do que o uso de tabelas EAV.

Nem o EAV nem a escolha de uma coluna JSON são abordagens ruins no seu caso, mas qual é realmente melhor para você depende do que você deseja fazer com os dados depois que eles são armazenados no banco de dados.

Se tudo o que você deseja é ter um produto com atributos definidos pelo usuário e você deseja ler o produto como um todo, o caminho JSON fornecerá um melhor desempenho para você, porque o produto inteiro estará localizado em uma tabela, você Você pode simplesmente decodificar o JSON recuperado do banco de dados e fazer o que quiser no frontend.

No entanto, se você deseja não apenas ler o produto como um todo, mas, com uma visão futura, talvez introduza a capacidade de filtrar produtos com determinados atributos (digamos cores), o uso da abordagem EAV aumentaria o desempenho dessa operação, conforme você pode filtrar produtos cujos nomes de atributo correspondem diretamente ao que você está procurando.

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

Se você tiver esse recurso com a coluna JSON, passar pelo modelo de atributo JSON consome mais recursos do que a comparação direta de cadeias.

Como desenvolvedor do back-end da API REST para aplicativos móveis, um exemplo com o qual estou trabalhando frequentemente é fornecer ao usuário uma visão geral das notificações por push recebidas por meio de algum centro de notificação no cliente móvel.

Como não estou planejando fazer consultas pesadas sobre os dados com frequência, a coluna JSON está completamente correta. Eu só quero fornecer os dados existentes em formatos diferentes para o usuário quando eles consultam, então retiro os dados do banco de dados e os despejo para o usuário. É ainda melhor porque a superfície das APIs REST é JSON, portanto, não sou obrigado a fazer nenhuma formatação adicional, como seria necessário no caso de um modelo EAV.