Comments 9
Ответить на собеседовании, что у EAV нет недостатков — это смело! Очень понравилось что автор решил детально разобраться в этом вопросе. Автору респект!
От себя приложу пару ссылок на схожие темы:
Как спроектировать БД с переменным количеством параметров?
Как хранить абстрактные модели данных в реляционных БД?
И особо! отдельно упомяну ссылочку из последнего обсуждения:
ООП в РСУБД
Последняя ссылка настоятельно рекомендуется к прочтению всем кто пытается разобраться с EAV.
От себя приложу пару ссылок на схожие темы:
Как спроектировать БД с переменным количеством параметров?
Как хранить абстрактные модели данных в реляционных БД?
И особо! отдельно упомяну ссылочку из последнего обсуждения:
ООП в РСУБД
Последняя ссылка настоятельно рекомендуется к прочтению всем кто пытается разобраться с EAV.
0
SELECT
r.code,
(SELECT COUNT(*)
FROM rubric_property rp
WHERE rp.rubric_id = r.id) property_count,
(SELECT COUNT(*)
FROM rubric_item ri
WHERE ri.rubric_id = r.id) item_count,
(SELECT COUNT(*)
FROM rubric_property rp
WHERE rp.rubric_id = r.id) + (
SELECT COUNT(*)
FROM rubric_item ri
WHERE ri.rubric_id = r.id) summary
FROM
rubric r
GROUP BY
r.code,
r.id
ORDER BY
summary DESC,
property_count DESC,
item_count DESC;
Так верстают только мудаки (с) А. Лебедев
+1
Эм, а в чем профит от использования таблицы/материализованного представления по сравнению с использованием просто таблицы, без всякого EAV?
+1
статья о том как уменьшить сайд эффекты от использования EAV, обсуждение преимущества EAV или просто таблиц за рамками статьи.
0
Извините, но у вас в этой статье написано:
единственная проблема это невозможность построить индексы для выборок
Так вот — не единственная.
+1
с удовольствием выслушаю их все :)
0
Для типовой реализации (одна таблица сущностей) есть еще как минимум три типовых недостатка:
- очень сложные запросы при необходимости построить джойн нескольких сущностей
- невозможность построить foreign key constraint с бизнес-смыслом (т.е. указать, что CustomerID может ссылаться только на сущность типа Customer)
- потери в производительности за счет того, что слишком большие таблицы (там и гуляние по ключам, и проблемы кэширования)
(это навскидку, можно и еще вспомнить)
+1
Sign up to leave a comment.
Идеальный каталог, оптимизация выборки данных