Ha utilizado una tabla Entidad-Atributo-Valor para registrar sus atributos.
Este es el opuesto de normalización.
Nombra la regla de normalización que te guió para poner diferentes atributos en la misma columna. No puedes, porque esta no es una práctica de normalización.
Para realizar su consulta con su diseño EAV actual, debe girar el resultado para obtener algo como si tuviera su tabla original.
SELECT * FROM (
SELECT
a.article_id,
a.title,
MAX(CASE attr_group WHEN 'ref_id' THEN attribute END) AS ref_id,
MAX(CASE attr_group WHEN 'dial_c_id' THEN attribute END) AS dial_c_id
-- ...others...
FROM test.articles_test a
INNER JOIN attributes attr ON a.article_id = attr.article_id
GROUP BY a.article_id, a.title) AS pivot
WHERE pivot.ref_id = '127712'
AND pivot.dial_c_id = 51
Si bien la consulta anterior puede producir el resultado que desea, el rendimiento será terrible. Tiene que crear una tabla temporal para la subconsulta, que contenga todos los datos de ambas tablas , luego aplique la cláusula WHERE contra la tabla temporal.
Está realmente mejor con cada atributo en su propia columna en su tabla original.
Entiendo que está tratando de permitir muchos atributos en el futuro. Este es un problema común.
Vea mi respuesta a Cómo diseñar una tabla de productos para muchos tipos de productos donde cada producto tiene muchos parámetros
Pero no deberías llamarlo "normalizado", porque no lo es. Ni siquiera está desnormalizado . Es desrelacional .
No puedes simplemente usar palabras para describir lo que quieras, especialmente no lo contrario de lo que significa la palabra. No puedo dejar salir el aire de la llanta de mi bicicleta y decir "La estoy inflando".
Comentó que está tratando de hacer que su base de datos sea "escalable". También malinterpreta lo que significa la palabra "escalable". Al usar EAV, está creando una estructura en la que las consultas necesarias son difíciles de escribir e ineficaces de ejecutar, y los datos ocupan 10 veces más espacio. Es lo opuesto a escalable.
Lo que quieres decir es que estás tratando de crear un sistema que sea extensible . Esto es complejo de implementar en SQL, pero describo varias soluciones en la otra respuesta de Stack Overflow a la que me vinculé. También te puede gustar mi presentación Modelado de datos extensible con MySQL .
