Uso de columnas MySql 5.7 JSON para EAV

Estoy desarrollando un producto de comercio electrónico y he podido implementar toda la funcionalidad y me queda permitir que los usuarios creen atributos adicionales para un producto. Ahora mismo tengo dos opciones.

EAV

EAV está mal visto, pero parece funcionar para Magento. Pero después de investigar todos los dolores de cabeza que causa, soy un poco reacio a usarlo

Usar columnas JSON en MySql 5.7

Esto es bastante nuevo y no lo he visto implementado en ningún otro lugar y estoy temiendo escaneos completos de tablas como resultado de consultar los atributos JSON. Pero después de leer este MySql 5.7 JSON , parecen recomendar el uso de JSON. y sería menos agotador que implementar algo como este consejo práctico de esquema MySql .

Mi pregunta es, aunque estoy predispuesto a usar la forma de columna JSON de almacenar atributos, ya que NoSQL no es una opción para mí, ¿hay algún inconveniente que sea más grave que usar tablas EAV?

Ni EAV ni elegir una columna JSON son malos enfoques en su caso, pero cuál es realmente mejor para usted depende de lo que quiera hacer con los datos una vez que estén almacenados en la base de datos.

Si todo lo que desea es tener un producto con atributos definidos por el usuario y desea leer el producto en su conjunto, la forma JSON le proporcionará un mejor rendimiento, ya que todo el producto se ubicará dentro de una tabla, usted simplemente puede decodificar el JSON recuperado de la base de datos y hacer lo que quiera en la interfaz.

Sin embargo, si no solo quiere leer el producto en su conjunto, sino que, con una visión futura, quizás pueda introducir la capacidad de filtrar productos con ciertos atributos (digamos color), el uso del enfoque EAV aumentaría el rendimiento de esta operación, ya que usted podría filtrar productos cuyos nombres de atributos coincidan directamente con el que está buscando.

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

Si tiene esta característica con la columna JSON, pasar por el modelo de atributo JSON ocupa más recursos que la comparación directa de cadenas.

Como desarrollador del backend API REST para aplicaciones móviles, un ejemplo con el que trabajo a menudo es proporcionar al usuario una descripción general de las notificaciones push que han recibido a través de algún centro de notificaciones dentro del cliente móvil.

Debido a que no planeo hacer consultas pesadas sobre los datos con frecuencia, la columna JSON está completamente bien. Solo quiero proporcionar al usuario los datos existentes en diferentes formatos cuando lo consultan, así que saco los datos de la base de datos y los vuelco al usuario. Es aún mejor porque la superficie de las API de REST es JSON, por lo que ni siquiera estoy obligado a hacer ningún formateo adicional, ya que debería hacerlo en el caso de un modelo EAV.