Você usou uma tabela Entity-Attribute-Value para registrar seus atributos.
Este é o oposto de normalização.
Nomeie a regra de normalização que o orientou a colocar diferentes atributos na mesma coluna. Você não pode, porque esta não é uma prática de normalização.
Para realizar sua consulta com seu design EAV atual, você precisa dinamizar o resultado para obter algo como se tivesse sua tabela 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
Embora a consulta acima possa produzir o resultado desejado, o desempenho será terrível. Ele precisa criar uma tabela temporária para a subconsulta, contendo todos os dados de ambas as tabelas , em seguida, aplique a cláusula WHERE na tabela temporária.
Você está realmente melhor com cada atributo em sua própria coluna em sua tabela original.
Entendo que você está tentando permitir muitos atributos no futuro. Esse é um problema comum.
Veja minha resposta paraComo projetar uma tabela de produtos para vários tipos de produtos em que cada produto tem muitos parâmetros
Mas você não deve chamá-lo de "normalizado", porque não é. Nem é desnormalizado . É desrelacional .
Você não pode simplesmente usar palavras para descrever o que quiser – especialmente o oposto do que a palavra significa. Não posso deixar o ar sair do pneu da minha bicicleta e dizer "Estou inflando".
Você comentou que está tentando tornar seu banco de dados "escalável". Você também não entende o que a palavra "escalável" significa. Ao usar o EAV, você está criando uma estrutura em que as consultas necessárias são difíceis de escrever e ineficientes de executar, e os dados ocupam 10 vezes o espaço. É o oposto de escalável.
O que você quer dizer é que está tentando criar um sistema extensível . Isso é complexo de implementar no SQL, mas descrevo várias soluções na outra resposta do Stack Overflow à qual vinculei. Você também pode gostar da minha apresentação Extensible Data Modeling with MySQL .
