A cd-ben és a lekérdezésben szereplő minden egyes dátum utolsó része
Előbb-utóbb mindenkinek szembe kell néznie azzal a feladattal, hogy minden egyes időpontra meghatározza a határértéket. Természetesen ezt a feladatot egyszerűen megoldja egy lekérdezés, melynek kapcsolata maximális dátumon kisebb vagy egyenlő dátumokkal. De ugyanaz a feladat megoldható az adatösszetétel segítségével. Ne beszéljünk arról, hogy a módszerek közül melyik termelékenyebb, minden egy adott feladattól függhet.
Első adatkészlet:
Példaként hozzon létre egy értékesítési jelentést, amelyben egy külön oszlop mutatja az árat az értékesítés napján érvényes árból.
Készítünk egy sor adatkérést "SalesOffers":
Most a jelentésünk így fog kinézni:
Most hozzá kell adni a jelentésben az "Árjegyzék az árlista" oszlopot, amelyet az értékesítés napján a "Nómenklatúra árai" információs regiszterből húzni fognak.
Második adatkészlet:
Hozzáadjuk a második adat-lekérdezés "Árak" -ot, akkor rögzített árakon fogunk árazni:
Ebben az adatkészletben három paraméter található: Dátum, Nómenklatúra és az árak típusa. Alulról a legérdekesebb Dátum és Nómenklatúra. Ezeket akkor használják, amikor adatkészleteket csatlakoztatnak, ahol az adatparaméter jelen van mind a virtuális, mind a kijelölt mezők paramétereiben.
Csatlakozások beállítása:
Folytassuk a módszer fő "chipjét" - a beállított kapcsolatokat:
Itt a legalapvetőbb a paraméterek helyes konfigurálása. Ha megad egy paramétert, akkor az ACD elküldi a kommunikációs vevőhöz csatlakozó paramétereket. Ezen paraméterek értékei a kommunikációs forrás megfelelő mezőinek értékei.
Ezután adja hozzá az árterületet az erőforrásokhoz és a kiválasztott mezőkhöz.
eredmény:
Most létrehozhat egy jelentést. Ellenőrizzük a jelentés helyességét a "Divan for Rest" példán.
A lekérdezésben:
Tekintse meg ugyanazt a problémát a lekérdezésben. Ez a feladat megoldható mind a beágyazott lekérdezések használatával, mind a. ideiglenes táblázatok. Megpróbáljuk megoldani a problémát ideiglenes táblázatok segítségével. Először a lekérdezés teljes szövegét adjuk meg, majd röviden elemezzük működésének alapelveit.
Ez a kötegelt kérelem három alkatrészt tartalmaz. Nézzük részletesebben.
Az első csomag tartalmaz kérelmet időszakra vonatkozó adatok és az ügyfél nómenklatúra és elhelyezi őket egy ideiglenes tábla vtBezTseny. Ezután fogjuk össze a táblázatot a tartományban az ár asztal és kap egy kis nyereséget, amely összekapcsolja a már összesített adatok.
A második lekérdezés csomagot állítottunk össze egy ideiglenes táblát a nyilvántartásban „TsenyNomenklatury” a nyilvántartásban szereplő információkat az információkat kiválasztjuk a maximális napja kisebb vagy egyenlő dátumokat. Az eredmény ez a kérés is helyezünk egy ideiglenes táblát (vtMaksPeriod). Lássuk, milyen adatok jutnak ehhez a táblázathoz:
A csomag utolsó kérésében ismét összekapcsoljuk az ideiglenes táblázatot az elem árával. Ehhez a táblázatot nómenklatúra és időszak szerint kapcsoljuk össze.
A lekérdezés végeredménye:
Ahogy látjuk az árak visszavonásának eredményeit mindkét esetben (az ACS-n keresztül és a kérelemen keresztül) ugyanazok voltak.
22. Igor (I_G_O_R) 45 14.11.10 14:42 Jelenleg a téma
1) ez egy lekérdezés egy cikkből, hibajavítással és indexek nélkül (anélkül, hogy az indexek a legjobb eredményeket mutatták):
így a kérelem nem függ a történelem és vyponyaetsya gyorsan, de valami nagyon hosszú először megkezdése után hosszú sql szerver fut, mi az oka, nem tudom, meg tudja mondani semmit cho.
Bold Enough; SamMix; vasyak319; WellMaster; serge_focus; Zircool; SirYozha; + 7 - Válasz Fordítás
23. Igor Iskhakov (Ish_2) 986 2010. november 14. hétfő, 16:39 Jelenleg a témában
(22) Tudtam, hogy válaszolna.
Kérdezte a rejtvényt.
Tehát jobb "átlagosan" az UT szokásos munkájáért.
Nagyon hasonló. hogy a lekérdezés futtatásakor az sql kiszolgáló először hozza létre és tölti be a regiszter összes indexének memóriáját a Periódus mezőben. Ez az index az a munka, amely az idő 90% -át fogyasztja. A későbbi elindítások során ez nem fordul elő, tehát csak 10 másodpercig.
DE.
Ha az első futás voltak jelentős változások az ár nyilvántartás (a felhasználók az induláshoz), a régi kódot a cache nem lehet használni, és újra létre kell hozni. És akkor a következő alkalommal, amikor elindítja a jelentését - újra a fékek.
Emlékszel az első cikkedre. Azóta óvatosan gondolkodom.
Tehát ez csak feltételezések.
Ha igazak. akkor jobban szeretném a cikkben megadott lekérdezést (minden szükséges korrekcióval és kiegészítéssel)
25. Igor (I_G_O_R) 45 11/14/10 18:17 Jelenleg a témában
(23), de hogyan lehet megismerni, hogy pontosan mit csinál az SCL mindezidáig, megnéztem a végrehajtási tervet, és nem változik
(24), hanem az indexekről: indexekkel valahol kétszer lassabban hajtotta végre a lekérdezést
26. Igor Iskhakov (Ish_2) 986 2010. november 14. kedd 18:28 Jelenleg online
(25) Jól vagy tévedek - meg tudod tudni, hogy egy forró kiszolgálón az első bejelentés után a jelentést a regiszterben Árak fel 1000 új rekordot. Ezután indítsa el a jelentését.
Ha az idő 400 másodperc - akkor igazam van. Ha 10 másodperc - akkor tévedek.
27. Igor (I_G_O_R) 45 11/14/10 10:03 PM Most a téma
(26), de igaza volt, de 50%)), hozta 10000 bejegyzés ugyanazon a napon, és a kérelem időpontjában elérte a 175 másodpercet, majd ismét a 10. Aztán átírtam az ideiglenes táblát a kérést, és hozzáadjuk egy lekérdezést a téma része az utóbbi, ennek eredményeként egy hideg kiszolgáló futási mind lekérdezi 45-50 másodpercig forró 35-40. Nem értem, miért voltak korábban stabilabb eredmények. Számos vizsgálatot végeztek, hogy a kérés nyer valamit a témáról, általában azt feltételezi, hogy ugyanúgy. Az utolsó kérés már nem tetszik, hogy a nómenklatúra-nyilvántartás csomó árak indexe (az én tárol adatokat csak TsenyNomenklatury - 236 MB, 730 MB, és az indexek), amelyeket szinte soha nem használt
28. Igor Iskhakov (Ish_2) 986 2010. november 14. hétfő, 22:31 Jelenleg a téma
(27) Zavaros voltam. Abszolút.
Összezavarta ez az 50% (175 sec). mostanra homályos (45-50), (35-40).