Alternativă eav, structura de bază

  • SQL
  • Proiectarea de baze de date
  • .NET
  • EAV
  • SQL Server


Magazinul online ridică problema parametrilor suplimentari ai bunurilor. Parametrii sunt definiți. Multe tipuri de bunuri. Primul lucru care vine în minte este arhitectura aproximativă a EAV. În Internet scrie că este rău și o alternativă - pentru fiecare tip de produs pentru a crea propriul tău tabel în baza de date.








Aș vrea să știu ce este rău la fel. Reale motive, și nu fictive că "nu freca." Și uitați-vă la structura bazei de date, cum să lucrați cu ea dacă faceți masa pentru fiecare tip de produs. Cum să arătați, de exemplu, toate produsele aflate în stoc. Sau toate mărfurile sunt roșii. Dacă există mai multe tabele pentru fiecare tip de produs ... nu mă pot gândi la o schemă optimă.


Și totuși ... cunosc inițial toți parametrii posibili, adică vor exista 2 tabele ... Produse și produseDescriptorii în care este scris ProductID (int), DescriptorID (int), DescriptorValue (str). De asemenea, știu ce ID înseamnă asta într-o etapă a creației. Ie acest lucru nu este un magazin online pentru bunuri abstracte și mărfurile pe care le cunosc. De exemplu, DescriptorID = 7 este responsabil pentru culoarea televizorului ...

"Executes" înseamnă că execută o interogare sql.

EXPLAIN ANALYZE arată. că cererea de a primi o carte a unui anumit produs (care are 10 parametri) este

0,15 ms. Partea PHP crede că mai mult decât interogarea este procesată în postgresql.

Nu am ascultat cursuri inteligente. Sunt inginer și rezolv sarcini specifice în condiții specifice. Afacerea nu este foarte interesată de aceste probleme tehnice. Dar reprezentanții afacerilor doresc orice tip de bunuri cu orice set de caracteristici și astfel, atunci când un nou tip nu trebuie să atragă dezvoltatori care vor fi ceva care să se conjure în structura meselor. Și, bineînțeles, acest lucru ar trebui să funcționeze rapid și fără rost, cu creșterea catalogului la un milion de poziții.
Așa că rezolv aceste probleme. Prin urmare, am un simplu motor PHP care păstrează un flux de 300 de solicitări din momentul generării paginii

0.015 sec pentru o lungă perioadă de timp (adică

25 de milioane pe zi). Pe un segment de 5 secunde, ar putea procesa o scurgere scurtă de încărcare de până la 1000 cereri / s cu generație
pagini

0,070 sec. În acest caz, partea PHP consumă mai puțin de 200 MB de memorie RAM. În general, întreaga mulțime de nginx + php-fpm + postgresql + redis mănâncă







Dacă se schimbă condițiile de mâine, ceea ce va arăta că EAV nu se potrivește cu mine, voi aplica o structură mai optimă fără probleme. Și, cu siguranță, nu voi fi niciodată un tip fanatic religios care țipă:% username%,% lang% shit și% struct% monstru monstru pentru că sunt inginer și practicant. Iar criteriul de adecvare pentru mine este implementarea eficientă a sarcinii prezentate și nu raționamentul abstract al teoreticienilor.

Ridicat de codul de solicitare, vă mulțumesc. După asta cu tine, nu este nimic de argumentat, îmi pare rău.

alekciy, ați demonstrat cazul degenerat al EAV. În cazul dvs., conceptul entității este degenerat, deoarece este reprezentat de un tabel separat. Ca structuri numite UDA (definite de utilizator atribute) și, într-adevăr, nu este nimic să vă faceți griji. În sensul că, în acest model, puteți utiliza în continuare baza de date fonduri în lupta pentru integritatea, în contrast cu clasica EAV, ceea ce este necesar pentru integritatea pentru a oferi propria lor, și într-un acces competitiv este Vemma și sarcină extrem de non-triviale și de a rezolva in mod eficient decât o face SGBD pentru modelul relațional clasic, uneori este pur și simplu imposibil.

Cu toate acestea, aplicabilitatea acestei abordări are o serie de limitări, la care, evident, vă potriviți. Dar în cazul dvs. particular, cred că este prea devreme să generalizați. Într-adevăr, nu este o problemă de a obține o singură carte de produs utilizând acest șir. Dar prezentarea unei ierarhii de mărfuri într-o formă tabelară este deja o problemă gravă, trebuie să executați cât mai multe asociații ca atributele definite în entitate. Dacă trebuie să selectați doar un singur atribut sau mai multe, folosind operatorul OR la ​​predicate, atunci nu există nici o problemă. Dar dacă trebuie să selectați valorile mai multor atribute, aplicând operatorul AND la predicatele selecției, acest lucru devine destul de problematic. De asemenea, trebuie remarcat faptul că prin această abordare, atributele definite de utilizator nu pot fi folosite de logica aplicațiilor. pentru că în ciclul de viață, aplicarea codului de atribut poate fi modificată de către utilizator.

Dar nu există nimic în neregulă cu EAV și UDA, sunt de acord cu dvs. Pur și simplu, aceste structuri au un domeniu de aplicare limitat. Și dacă UDA poate fi folosită undeva, atunci domeniul de aplicare al EAV este neglijabil. Acestea sunt aplicații care funcționează cu entități independente, care pot fi modificate în modul de acces exclusiv. Cred că acest domeniu este la Stolk restrânge acest caz, pentru care se aplică abordarea EAV, ar putea fi descrisă ca fiind excepțională.

> Într-adevăr, nu este o problemă de a obține o singură carte de produs utilizând acest șir.
Ierarhia într-un tabel separat sau sub forma AL NS asupra situației. Legătura cu lista de frunze a copacului este prin masa a treia. Aceasta acoperă cerințele actuale ale afacerii. În special, caută atributele specifice nu sunt necesare pentru logica de căutare magazin online de haine de „Vreau o dimensiune XX tricou roșu“, de obicei duce la tricouri de probă rapide, folosind un index și o mai lent, dar în cadrul aplicației rapid, filtru de valori de atribute. Aceasta este mai mult decât acoperă cerințele actuale și cu o marjă mare. Dacă a fost un computer hardware director dupa atributele set, atunci desigur, nu ar fi folosit o astfel de structură.

Pentru sfaturi utile pentru UDA mulțumiri.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: