Du har brugt en Entity-Attribute-Value-tabel til at registrere dine attributter.
Dette er det modsatte normalisering.
Navngiv den normaliseringsregel, der guidede dig til at sætte forskellige attributter i samme kolonne. Det kan du ikke, fordi dette ikke er en normaliseringspraksis.
For at udføre din forespørgsel med dit nuværende EAV-design, skal du dreje resultatet, så du får noget, som om du havde din originale tabel.
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
Selvom ovenstående forespørgsel kan give det resultat, du ønsker, vil ydeevnen være forfærdelig. Den skal oprette en midlertidig tabel for underforespørgslen, der indeholder alle data fra begge tabeller , og anvend derefter WHERE-sætningen mod temp-tabellen.
Du er virkelig bedre stillet med hver egenskab i sin egen kolonne i din oprindelige tabel.
Jeg forstår, at du forsøger at tillade mange egenskaber i fremtiden. Dette er et almindeligt problem.
Se mit svar tilSådan designer man en produkttabel til mange slags produkter, hvor hvert produkt har mange parametre
Men du skal ikke kalde det "normaliseret", for det er det ikke. Det er ikke engang denormaliseret . Det er derelationelt .
Du kan ikke bare bruge ord til at beskrive alt, hvad du vil - især ikke det modsatte af, hvad ordet betyder. Jeg kan ikke slippe luften ud af mit cykeldæk og sige "Jeg puster det op."
Du kommenterede, at du forsøger at gøre din database "skalerbar". Du misforstår også, hvad ordet "skalerbar" betyder. Ved at bruge EAV skaber du en struktur, hvor de nødvendige forespørgsler er svære at skrive og ineffektive at udføre, og dataene tager 10x plads. Det er det modsatte af skalerbar.
Det du mener er, at du forsøger at skabe et system, der er udvidbart . Dette er komplekst at implementere i SQL, men jeg beskriver flere løsninger i det andet Stack Overflow-svar, som jeg linkede til. Du kan måske også lide min præsentation Extensible Data Modeling with MySQL .