Използвали сте таблица Entity-Attribute-Value, за да запишете вашите атрибути.
Това е обратното на нормализиране.
Назовете правилото за нормализиране, което ви накара да поставите различни атрибути в една и съща колона. Не можете, защото това не е практика за нормализиране.
За да изпълните заявката си с текущия си дизайн на EAV, трябва да завъртите резултата, така че да получите нещо, сякаш имате оригиналната си таблица.
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
Въпреки че горната заявка може да доведе до желания резултат, производителността ще бъде ужасна. Той трябва да създаде временна таблица за подзаявката, съдържаща всички данни от двете таблици , след което приложете клаузата WHERE към временната таблица.
Наистина е по-добре с всеки атрибут в отделна колона в оригиналната ви таблица.
Разбирам, че се опитвате да разрешите много атрибути в бъдеще. Това е често срещан проблем.
Вижте моя отговор наКак да проектираме продуктова таблица за много видове продукти, където всеки продукт има много параметри
Но не бива да го наричате "нормализиран", защото не е така. Дори не е денормализиран . Това е дерелационен .
Не можете просто да използвате думи, за да опишете всичко, което искате - особено не обратното на това, което означава думата. Не мога да изпусна въздуха от гумата на велосипеда си и да кажа "Напомпам я."
Коментирахте, че се опитвате да направите базата си данни "мащабируема". Освен това разбирате погрешно какво означава думата "мащабируем". Използвайки EAV, вие създавате структура, в която необходимите заявки са трудни за писане и неефективни за изпълнение, а данните заемат 10x пространство. Това е обратното на мащабируемото.
Това, което имате предвид, е, че се опитвате да създадете система, която е разширяема . Това е сложно за изпълнение в SQL, но описвам няколко решения в другия отговор на Stack Overflow, към който свързах. Може да ви хареса и моята презентация Разширяемо моделиране на данни с MySQL .
