Трябва ли да използвам EAV модел?

Проектирам своята база данни/домейн за приложение за електронна търговия и ми е трудно да разбера как да съхранявам продукти.

Уебсайтът ще продава широка гама от продукти, химикалки, прашки, татуировки, чадъри, всичко. Всеки от тези продукти ще споделя няколко общи атрибута, височина, ширина, дължина, тегло и т.н., но някои продукти имат специални данни. Например химикалките имат различни цветове на мастилото и накрайниците/капаците, а брошурите могат да имат различни видове гънки. Досега съм измислил около 20+ допълнителни атрибута, но тези атрибути може да се прилагат само за 1% от продуктите на уебсайта.

Така че се чудя дали е подходящо да внедря EAV модел за обработка на допълнителните данни. Имайки предвид, че когато клиентите разглеждат сайта в предния край, ще има филтрираща странична лента като на eBay и carsales.com.au. (Така че имайте предвид, че ще има доста запитвания)

Не мисля, че е практично да се прилага наследяване на Class Table, тъй като системата трябва да остане гъвкава. Това е така, защото в бъдеще може да имаме повече атрибути с нови видове продукти.

Другото нещо, което обмислих, е използването на NoSQL база данни (вероятно MongoDB), но имам малък опит с тези типове бази данни, ще реши ли проблема ми?

Преглед на опциите:

  1. Обект с единични продукти с много колони
  2. Обект с отделни атрибути (EAV)
  3. Преминете към постоянство без схема

В процес съм на изграждане на прототип с обект на атрибути, за да видя колко е гъвкав, и тествам производителността и как заявките излизат извън контрол.

РЕДАКТИРАНЕ: Аз, разбира се, съм отворен за всякакви други решения.


php database-design magento doctrine-orm entity-attribute-value
person Cobby    schedule 01.11.2010    source източник
comment
Има ли конкретна причина да изграждате ръчно приложение за електронна търговия? Може да е трудно, опасно и може би малко ненужно...   -  person Jonathan Day    schedule 01.11.2010
comment
Току-що намерих този въпрос, който изглежда почти същото като това, което питаш.   -  person BenV    schedule 01.11.2010
comment
@BenV, въпреки че въпросът е подобен, отговорите вероятно ще бъдат доста различни, особено по отношение на Magento. Първоначално Magento наистина имаше затруднения с производителността на EAV, но те разрешиха това чрез внимателно кеширане (заявка, модел, html-блок и цяла страница) и незадължителна денормализация. Това са нови разработки, откакто беше зададен този въпрос, и заслужава да се зададе отново въпросът в този контекст, IMHO.   -  person Jonathan Day    schedule 01.11.2010
comment
Приложението, което правя, е много различно от обикновено приложение за електронна търговия. Единственото възможно съществуващо решение, което открих в PHP, е Magento, но изглежда доста сложно и ще ми бъде също толкова трудно/отнемащо време да го науча, след което да направя своя собствена от нулата.   -  person Cobby    schedule 01.11.2010
comment
@Cobby, честно казано, познаваш изискванията си по-добре от всеки друг, но с цялото ми уважение, ако смяташ, че изучаването на Magento е сложно, тогава писането на собствено приложение за електронна търговия не е нещо, което бих препоръчал. Има буквално десетки хиляди часове за разработчици и архитекти, вложени в приложения като Magento, и много битки по пътя. Когато работите с парите на клиенти или вашите клиенти, бих предпочел някой друг да е правил тези грешки в миналото, а не аз...   -  person Jonathan Day    schedule 01.11.2010

Отговори (3)


arrow_upward
69
arrow_downward

Страхотен въпрос, но разбира се, няма "един верен начин". Според @BenV, Magento наистина използва модела EAV. Опитът ми с него е изключително положителен, но спъва други потребители. Някои съображения:

1. Производителност. EAV изисква сложни обединения с множество таблици, за да попълни вашия обект със съответните атрибути. Това води до удар в производителността. Това обаче може да бъде смекчено чрез внимателно кеширане (на всички нива в стека, включително кеширане на заявки) и селективно използване на денормализиране. Magento позволява на администраторите да избират денормализиран модел за категории и продукти, където броят на SKU го гарантира (обикновено в хиляди). Това от своя страна изисква наблюдатели, които задействат повторно индексиране (винаги добре!) и актуализации на „плоските“ денормализирани таблици, когато данните за продукта се променят. Това също може да бъде планирано или ръчно задействано с подкана към администратора.

2. Сложност на потребителите на трети страниАко някога планирате да направите това приложение достъпно за други потребители, мнозина ще намерят EAV за твърде сложно и в крайна сметка ще се сблъскате с много блеене и неинформирано злоупотреба в потребителските форуми (реф. Magento! !).

3. Бъдеща разширяемост и архитектура на плъгини. Няма съмнение, че моделът EAV наистина се налага, когато разширяемостта е фактор. Много е лесно да добавите нови атрибути в модела, като същевременно минимизирате риска от нарушаване на съществуващия ORM и код на контролера.

4. Промени в типа данни EAV наистина прави малко по-трудно променянето на типовете данни на атрибутите. Ако вашият първоначален дизайн изисква конкретен тип данни за атрибут, който се променя в бъдеще (да речем int до varchar), това означава, че ще трябва да мигрирате всички записи за този атрибут към съответната таблица, която съответства на новия тип данни. Разбира се, пуристите биха предложили да получите правилния дизайн от първия път, но реалността понякога се намесва!

5. Ръчно импортиране на продукти Едно нещо, което EAV прави почти невъзможно, е импортирането на продукти (или други обекти) в базата данни с помощта на SQL и/или CSV/XML в стил phpMyAdmin. Ще трябва да напишете модул за импортиране, който приема структурираните данни и ги предава през моделния слой на приложението, за да ги запази в базата данни. Това допринася за вашата сложност.

person Jonathan Day    schedule 01.11.2010
comment
Не мисля, че производителността ще бъде основна грижа, Doctrine 2 вече има кеш за заявки, плюс това ще внедря собственото си ниво. Освен това е важно да запомните, че атрибутите имат само основните цели: 1. За филтриране на списъци с продукти 2. Показване на продуктова страница. Данните, съдържащи се в атрибутите, са само метаданни и не са необходими за работата на приложението. Предполагам, че са малко като тагове, в който случай EAV изглежда практично. - person Cobby; 01.11.2010
comment
Точката на @Cobby Jonathan относно кеширането стои. Как генерирате суми за филтрите? Как да обслужвате ефективно страници за голям брой клиенти? Ако настоявате да създадете това сами, поне си направете услуга и прегледайте промените, които Magento направи в тяхната EAV система, за да позволи мащаб. - person Joseph Mastey; 01.11.2010
comment
Просто играя на защитник на дяволите - Моите чувства точно относно EAV: weblogs.sqlteam.com/davidm /articles/12117.aspx#42216 Не съм единственият, който се чувства по същия начин: activecodeline.net/f-magento-eav - person B00MER; 29.03.2011
comment
Предимство на EAV модела е, че промените в схемата обикновено могат да бъдат постигнати без промяна на схемата на базата данни. Това е важно, защото в MySQL операторите ALTER TABLE заключват таблицата, за да предотвратят всички четения и записи по време на промени в схемата. Следователно, ако трябва да промените схема на голяма таблица, това може да доведе до проблеми със заключването и потенциални прекъсвания, докато ALTER TABLE работи. (Помислете за много големи и критични таблици като клиенти или продукти в сайт за електронна търговия). - person Jim OHalloran; 20.01.2012
comment
@JimOHalloran, В производствена среда, където заключването е сериозен проблем, би било доста стандартно да имате настройка на главен/подчинен, да промените подчинения, да синхронизирате отново с главния, след това да размените главния/подчинения и да следвате същия процес. Може да се наложи да напишете свой собствен инструмент за синхронизиране на 2-те бази данни, когато те работят на различни структури, но би било доста лесно. - person Matt Dunbar; 05.06.2013

arrow_upward
0
arrow_downward

Количката за пазаруване с отворен код Magento позволява персонализирани атрибути за техните продукти, използвайки EAV дизайн. Можете да разгледате тяхната схема на база данни тук.

person BenV    schedule 01.11.2010
comment
Да, вече прегледах дизайна на тяхната база данни, на който базирам своя прототип. Въпросът ми не е за прилагането на EAV... Вече знам как да го използвам. Въпросът ми е за архитектурната практичност на използването на EAV в производствена среда. - person Cobby; 01.11.2010

arrow_upward
0
arrow_downward

Предлагам ви да разгледате по-отблизо Doctrine 2 ORM с OXM плъгин за него (https://github.com/doctrine/oxm). Той ще реши проблема ви с различни атрибути. Разбира се, ще трябва да изградите индекси за потребителски атрибути с възможност за търсене, но не мисля, че ще е проблем :)

Ако не ви интересува броя на членовете на общността, тогава можете да използвате и MongoDB.

person Ivan Chepurnyi    schedule 11.03.2011