![]() |
Second Opinion
Folosind serviciul second opinion ne puteți trimite RMN-uri, CT -uri, angiografii, fișiere .pdf, documente medicale. Astfel vă vom putea da o opinie neurochirurgicală, fără ca aceasta să poată înlocui un consult de specialitate. Răspunsurile vor fi date prin e-mail în cel mai scurt timp posibil (de obicei în mai putin de 24 de ore, dar nu mai mult de 48 de ore). Second opinion – Neurohope este un serviciu gratuit. www.neurohope.ro |
De cate interogari e nevoie pentru a importa 1600 produse intr-un magazin online popular?
Last Updated: Mar 13 2021 11:16, Started by
dani.user
, Mar 11 2021 11:39
·
0

#19
Posted 12 March 2021 - 11:49

Da, doar ca baza noastra de date e actualizata mereu asa ca niciodata nu putem folosi Query Cache. De fapt l-am dezactivat, era un overhead inutil.
|
#20
Posted 12 March 2021 - 13:11

Daca erau cereri de citire/afisare pagina intelegeam ca pentru fiecare mai executa si CMSu diverse cereri in spate. Dar fiind o cerere de import nu vad ce vina ar avea CMSul. Nu vad de ce existenta CMSului (fata de o platforma dedicata) ar fi cauza tehnica pentru atat de multe interogari. - ai un sistem dedicat; adaugi coloana NrComponente in tabelul Articole, cu tipul INT si inserezi valoarea in tabel - ai un sistem generic: trebuie sa adaugi inregistrari in tabelul ExtendedProperties (unde sa spui ca va exista proprietatea NrComponente de tip INT), apoi inserezi si o legatura intre tabelul Articole si noua proprietate din ExtendedProperties (unde practic spui ca inregistrarile din Articole au si respectiva proprietate), apoi mai trebuie sa inserezi si valoarea efectiva intr-un tabel ExtendedPropertiesValues (unde o sa ai un FK catre Articole si un FK catre ExtendedProperties) cand o sa compari query-urile la import, o sa descoperi ca sistemul generic mai face inca 2 interogari si 1 insert, pentru ca trebuie sa afle cheia din ExtendedProperties (dupa nume), apoi sa insereze atat in Articole cat si in ExtendedPropertiesValues tldr: un sistem generic are nevoie de o infrastructura destul de stufoasa, asa ca operatiunile simple (din perspectiva utilizatorului) se vor traduce intr-o multime de query-uri catre baza de date. @RedDev: sistemul care sta mereu la 99.99% e utopic, nu poate fi realizat. ar fi perfect, pentru ca ar insemna ca nici un query nu e pus in asteptare (adica nu ajunge la 100%), dar nici resursele nu stau degeaba asteptand orele de varf. pe de alta parte, un sistem care "sa stea ca mai mult in asteptare (load 0)" e pur si simplu o irosire de resurse. Edited by _Smiley_, 12 March 2021 - 13:14. |
#21
Posted 12 March 2021 - 23:09

Dupa o analiza mai atenta a codului se pare ca apeleaza codul CMS'ului pentru postari si metadate pentru a stoca fiecare produs. Astfel se ajunge la o multime de operatiuni pentru fiecare coloana a fiecarui rand. Chiar si coloanele lasate goale cauzeaza diverse operatii de stergere (a cui nu stiu daca produsul tocmai a fost inserat si a primit un id nou...).
De ce au ales calea asta in loc de tabele special facute pentru produse (daca tot au acces la baza de date) doar ei stiu. Probabil comoditate/mai putin cod de scris. Au si tabele dedicate pentru alte informatii. |
#22
Posted 13 March 2021 - 11:16

De curiozitate, am vrut sa vad cum se comporta o platforma populara pentru magazine online din punct de vedere al resurselor necesare. Asa ca am importat 1600 produse aleatoare stocate intr-un csv de vreo 800 KB (incape pe o discheta). Cate interogari SQL credeti ca a executat platforma pana la finalizarea importului? [To be continued] Pentru un singur rendering de pagină, mai toate platformele open-source scrise în php fac câteva sute de select și câteva insert/update. Te doare capul. Nu m-aș mira dacă ai găsit n x m la import. |
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users