Mai devreme sau mai târziu, toată lumea se confruntă cu sarcina de a obține o limită pentru fiecare dată. Desigur, această sarcină este rezolvată pur și simplu printr-o interogare cu o conexiune la o dată maximă de la date mai mici sau egale.
Dar aceeași sarcină poate fi rezolvată cu ajutorul compoziției datelor. Să nu vorbim despre care dintre căi este mai productivă, totul poate depinde de o sarcină specifică.
Primul set de date:
De exemplu, vom crea un raport de vânzări, în care o coloană separată va afișa prețul din prețul de la data vânzării.
Vom crea un set de solicitări de date "SalesOffers":
Acum, raportul nostru va arăta astfel:
Acum trebuie să adăugați în raport coloana "Preț pe lista de prețuri", care va fi scos din registrul de informații "Prețurile nomenclatorului" la data vânzării.
Al doilea set de date:
Adăugăm al doilea set de interogări de date "Prețuri", vom lua prețurile pentru un tip fix de prețuri:
În acest set de date există trei parametri: data, nomenclatura și tipul prețurilor. Din partea de jos sunt cea mai interesantă dată și nomenclatură. Acestea vor fi utilizate la conectarea seturilor de date, unde parametrul de date este prezent atât în parametrii tabelului virtual, cât și în câmpurile selectate.
Setați conexiunile:
Să trecem la principalul "chip" al acestei metode - conexiunile stabilite:
Aici cel mai important este să configurați corect parametrii. Dacă este specificat un parametru, ACD trimite parametrii specificați în conexiune la receptorul de comunicații. Valorile acestor parametri sunt valorile câmpurilor corespunzătoare ale sursei de comunicare.
Apoi, adăugați câmpul de preț la resurse și la câmpurile selectate.
rezultat:
Acum puteți genera un raport. Să verificăm corectitudinea raportului utilizând exemplul "Divan pentru odihnă".
În interogare:
Luați în considerare soluția aceleiași probleme în interogare. Această sarcină poate fi rezolvată atât cu utilizarea interogărilor imbricate, cât și cu. tabele temporare. Să încercăm să rezolvăm problema utilizând tabele temporare. Mai întâi, oferim întregul text al interogării și apoi analizăm pe scurt principiul funcționării sale în părți.
Această solicitare de lot conține trei subcotări. Să le analizăm mai detaliat.
Prima solicitare a pachetului grupează datele după perioadă, contrapartidă și nomenclatură și le plasează în tabelul temporar. Apoi vom intra în acest tabel cu tabelul prețurilor din nomenclatură și vom obține un mic câștig în faptul că vom grupa deja datele deja grupate.
În cea de-a doua solicitare a pachetului, conectăm tabelul temporar cu registrul de informații "Nomenclature Prices", în timp ce din registrul de informații selectăm data maximă din datele mai mici sau egale. Rezultatul acestei interogări este, de asemenea, plasat într-o tabelă temporară (WTMaxPeriod). Să vedem ce date intră în acest tabel:
În ultima solicitare a pachetului, conectăm încă o dată tabelul temporar cu tabelul cu prețurile elementului. Pe aceasta legăm tabelul după nomenclatură și perioadă.
Rezultatul final al interogării:
După cum vedem rezultatele retragerii prețurilor în ambele cazuri (prin ACS și prin cerere) erau aceleași.
22. Igor (I_G_O_R) 45 14.11.10 14:42 În prezent în discuție
1) aceasta este o interogare dintr-un articol cu corecții de eroare și fără indexuri (fără ca indicii să prezinte cele mai bune rezultate):
astfel încât interogarea mea nu depinde de istorie și este mai rapidă, dar ceva foarte lung pentru prima dată după ce a rula serverul SQL a fost rulat pentru o lungă perioadă de timp, nici măcar nu știu ce este, poate veți spune ceva.
Destul de îndrăzneț; SamMix; vasyak319; WellMaster; serge_focus; Zircool; SirYozha; + 7 - Răspunde
23. Igor Iskhakov (Ish_2) 986 Luni, 14 Noiembrie 2010 16:39 Momentan pe subiect
(22) Știam că vei răspunde.
Ai cerut puzzle-ul.
Deci este mai bine "în medie" pentru munca obișnuită în UT.
Foarte similar. că atunci când executați interogarea dvs. prima dată când serverul SQL creează și încarcă în memorie TOATE indicele registrului în câmpul Perioadă. Este lucrul la acest indice care consumă 90% din timp. În timpul lansărilor ulterioare, acest lucru nu se întâmplă, prin urmare, timp de numai 10 secunde.
DAR.
Dacă după primul început au avut loc schimbări serioase în registrul de prețuri (utilizatorii au început să lucreze), atunci vechiul index din memoria cache nu poate fi folosit și ar trebui să fie recreat. Și apoi data viitoare când rulați raportul dvs. - din nou frânele.
Îți amintești primul tău articol. De atunci am prezis cu prudență.
Deci = acestea sunt doar ipoteze.
Dacă sunt adevărate. atunci aș prefera interogarea dată în articol (cu toate corecțiile și completările necesare)
25. Igor (I_G_O_R) 45 11/14/10 18:17 În prezent în subiectul respectiv
(23), dar cum să aflu exact ce a făcut SCL tot timpul, m-am uitat la planul de execuție și nu se schimbă
(24), dar cu privire la indicii: cu indicii undeva de două ori interogarea a fost executată mai lent
26. Igor Iskhakov (Ish_2) 986 Marți, 14 Noiembrie 2010 18:28 În prezent online
(25) Am dreptate sau rău - puteți afla dacă pe un server fierbinte după prima lansare a raportului dvs. în registru Prețurile au introdus 1000 de înregistrări noi. Și după aceea începeți raportul.
Dacă timpul este de 400 de secunde - atunci am dreptate. Dacă 10 secunde - atunci mă înșel.
27. Igor (I_G_O_R) 45 11/14/10 10:03 PM Acum in thread
(26), dar el a avut dreptate, dar 50%)), a adus 10.000 de intrări în aceeași zi și momentul cererii sa ridicat la 175 de secunde, și apoi din nou la 10. Apoi am rescris tabelul temporar cererea și a adăugat la o interogare dintr-o secțiune subiect a acestuia din urmă, ca rezultat pe un server rece, timpul de execuție al ambelor cereri este de 45-50 de secunde, la 35-40 de cald. Nu înțeleg de ce mai devreme au fost rezultate mai stabile. Multe teste au fost efectuate, că cererea mea va câștiga ceva de la un subiect, în general, se va presupune că în același mod. Ultima solicitare este acum nu-mi place că în registru nomenclatura bunch Prețurile Index (în datele mele de bază de date numai TsenyNomenklatury - 236 MB, 730 MB și indicii), care aproape niciodată nu sunt utilizate
28. Igor Iskhakov (Ish_2) 986 Luni, 14 Noiembrie 2010 22:31 În prezent în thread
(27) Am fost confuz. Absolut.
Confuzat de acest 50% (175 sec). sunt obscure pentru moment (45-50), (35-40).
Trimiteți-le prietenilor: