- SQL
- Проектування баз даних
- .NET
- EAV
- SQL Server
В інтернет-магазині постає питання про додаткові параметри товарів. Параметрів кінцеве число. Багато типів товарів. Перше що приходить в голову - приблизна архітектура EAV. В інтернетах пишуть що це погано і альтернатива - для кожного типу товару створювати свою таблицю в базі.
Хотілося б знати, чим же все таки це погано. Реальні причини, а не вигадані що «ни праці». І подивитися структуру бази, як з нею працювати якщо зробити для кожного типу товару свою таблицю. Як показати наприклад усі товари в наявності. Або усі товари червоного кольору. Якщо є кілька таблиць для кожного типу товару ... Не можу придумати оптимальну схему.
І ще ... Я спочатку знаю всі можливі параметри, тобто буде 2 таблиці ... Products і ProductsDescriptors в якій записано ProductID (int), DescriptorID (int), DescriptorValue (str). І знаю який ID що має на увазі на етапі створення. Тобто це не інтернет-магазин для абстрактних товарів, а товари я знаю. Наприклад DescriptorID = 7 відповідає за колір телевізора ...
«Відпрацьовує» означає виконує sql запит.
EXPLAIN ANALYZE показує. що запит отримання картки конкретного товару (у якого 10 параметрів) займає
0.15 мс. PHP частина думає більше, ніж запит відпрацьовується в postgresql-е.
Я всяких розумних курсів не слухав. Я інженер і вирішую конкретні завдання в конкретних умовах. Бізнес мало цікавлять ці технічні заморочки. Але представникам бізнесу хочеться будь-яку кількість типів товару з будь-яким набором характеристик і так, що б при появі нового типу не доводилося залучати розробників які буду щось там чаклувати в структуру таблиць. І звичайно ж це має швидко і безбагово працювати при збільшенні каталогу до мільйона позицій.
Ось і я вирішую ці завдання. Тому у мене простий PHP движок які тримає потік в 300 запитів / сек з часу генерації сторінки
0,015 сек довготривало (тобто
25 мільйонів на добу). На відрізку в 5 секунд він міг обробити короткочасний сплеск навантаження до 1000 запитів / сек з генерацією
сторінок
0.070 сек. При цьому PHP частина споживає менше 200 МБ ОЗУ. В цілому ж вся зв'язка nginx + php-fpm + postgresql + redis їсть
Якщо завтра зміняться умови які покажуть, що EAV мені не підходить, я без проблем застосую більш оптимальну структуру. І вже точно я ні коли не буду релігійним фанатиком кричущим:% username%, твій% lang% гавно і% struct% монструозної монстр тому як я інженер і практик. І критерій адекватності для мене - ефективне виконання поставлено завдання, а не абстрактні міркування теоретиків.
Розсмішили кодом запиту, спасибі. Після такого з Вами нема про що сперечатися, вибачте.
alekciy, ви продемонстрували вироджений випадок EAV. У вашому випадку поняття entity - вироджена т.к представлено відокремленої таблицею. Подібні структури називають UDA (user defined attributes) і, дійсно, в них немає нічого страшного. В тому сенсі, що в цій моделі ще можна використовувати засоби датабази для контролю цілісності, на відміну від класичної EAV, де доводиться цілісність забезпечувати самостійно, а в умовах конкурентного доступу це вемьма і вельми не тривіальна задача, і вирішити її ефективніше ніж це робить СУБД для класичної реляційної моделі, часом, буває просто неможливо.
Однак застосовність такого підходу має ряд обмежень, в які, ви, очевидно, вписується. Але по вашого окремого випадку, мені здається, рано узагальнювати. Дійсно, отримати картку одного товару, використовуючи дану струтури не складає проблеми. Але уявити товарну ієрархію в табличному вигляді це вже серйозна проблема, вам доведеться виконати стільки ж Джойна, скільки атрибутів визначено у сутності. Якщо вам потрібно здійснювати відбір лише по одному атрибуту або ж за кількома, застосовуючи оператор OR до предикатам, то теж проблем немає. Але якщо вам потрібно відбирати за значеннями кількох атрибутів, до предикатам відбору застосовуючи оператор AND, це стає вельми проблемотічно. Варто так само відзначити, що при такому підході, визначені користувачем атрибути не можуть бути використані логікою програми. Оскільки в життєвому циклі додаток код атрибута може бути змінений користувачем.
Але в тому, що в EAV і в UDA дійсно нічого немає нічого страшного, я з Вами повністю згоден. Просто ці структури мають обмежену сферу застосування. І якщо UDA ще можна десь використовувати, то область застосування EAV - незначна. Це програми, що працюють з відокремленими сутностями, модифікуються в режимі монопольного доступу. Мені здається ця область на столко вузька, що випадок, для якого підхід EAV застосуємо, цілком можна назвати винятковим.
> Дійсно, отримати картку одного товару, використовуючи дану струтури не складає проблеми.
Ієрархія в окремій таблиці у вигляді AL або NS по ситуації. Зв'язок з товар-ліст_дерева через третину таблицю. Це покриває поточні бізнес вимоги. Зокрема пошук по конкретним атрибутам не потрібно, для інтернет магазину одягу логіка пошуку «хочу червону сорочку ХХ розміру» зазвичай призводить до швидкої вибірці сорочок з використанням індексу і повільнішою, але в рамках програми швидкої, фільтрації за значеннями атрибутів. Це з лишком перекриває поточні вимоги причому з великим запасом. Якби це був каталог комп'ютерного обладнання з частим пошуком по набору атрибутів, то звичайно ж така структура б не використовувалася.
За наводку на UDA спасибі.