1s 8 kötegelt kérés. Egyszerű kérések. A szuboptimális lekérdezési teljesítmény okai

Elemezzük, hogy a kérések szövegeinek szintaxisa hogyan egyszerű példa: Tartott dokumentum Elfogyasztható táblázatos részben tartalmazza Áruk az eladó áruk listája és mennyisége. Az ilyen dokumentum elkészítésekor biztosítani kell az egyenlegfelhalmozási nyilvántartásban tárolt negatív egyenlegek ellenőrzését Áruk maradványai.

A konfigurációs felépítés az ábrán látható.

(16,22 kilobájt) Letöltések száma: 64

Alkossunk lekérdezést a dokumentum táblázatos részéhez és a virtuális táblához Maradványok felhalmozási nyilvántartás. A dokumentumban az esetleges duplikált sorokat figyelembe vesszük, ehhez csoportosítjuk a rekordokat.

// Áthalad a nyilvántartáson

EndCycle;

Vége eljárás

Természetesen a kapott kérés egyáltalán nem optimális. Optimalizáljuk beágyazott lekérdezések segítségével: Csoportosítsuk a bizonylat táblázatos részét az egyenlegtáblázathoz való kapcsolódás előtt, az egyenlegszámítás feltételének értékeként adjuk át az árulistát a virtuális tábla paraméterei közé. Ennek eredményeként kérésünk a következő formában jelenik meg:

Ha egy lekérdezésnél különböző regiszterek maradványaiból kellene adatokat szerezni, akkor a szűrőérték, és így a második részlekérdezésünk a virtuális táblák minden paraméterében megismétlődik, természetes, hogy a rendszer újra hozzáfér az adatbázishoz. minden egyes részlekérdezéshez az adatok beszerzéséhez.

Ideiglenes asztalok

Nem emlékszem, melyik kiadástól vált lehetségessé ideiglenes táblák használata a lekérdezésekben. Ehhez az "Ideiglenes táblakezelő" objektumot használják. Valójában az ideiglenes táblakezelő írja le az ideiglenes táblák névterét, és felelős azok létrehozásáért és megsemmisítéséért az adatbázisban.

Maguk az ideiglenes táblák valójában fizikailag az adatbázisban jönnek létre, ezért óvatosan kell bánni velük, mivel a lemezes alrendszer jelenleg a technológia leglassabb része, és ettől közvetlenül függ a táblák létrehozásának és megsemmisítésének sebessége.

Írjuk át a lekérdezést ideiglenes táblák használatára. Helyezzük ideiglenes táblákba a dokumentum csoportosított táblázatos részét és a virtuális táblák szűrésére szolgáló termékek listáját:

Feladáskezelési eljárás (hiba, feladási mód)

MBT = New TemporaryTable Manager;

QueryResult = Query.Execute();
Selection = QueryResult.Select();

While Selection.Next() Loop

//Negatív egyenlegek ellenőrzése

// Áthalad a nyilvántartáson

EndCycle;

Vége eljárás

Ha ideiglenes táblákat használ a lekérdezés szövegében, használja az utasítást Hozzászólásúj ideiglenes tábla létrehozásához, ebben az esetben a rendszer nem ennek a táblának a tartalmát küldi el a lekérdezés eredményébe (lásd a fenti szöveg 1. és 2. megjegyzését), hanem az ideiglenes táblában elhelyezett rekordok számát, ha akarja, ne fogadja el ezt az értéket.

Használhatja az utasítást is Elpusztítani ebben az esetben az ideiglenes tábla megsemmisül, ellenkező esetben az ideiglenes táblák az ideiglenes táblakezelő objektummal együtt.

Fő lekérdezésünkben az ideiglenes táblák neveit használtam az adatgyűjtés forrásának jelzésére (azokhoz szinonimát kell rendelni, amit a szövegben látunk). Az ideiglenes táblákat többször is használhatja forrásként, ami ügyes használat esetén egyszerre csökkenti a lekérdezés szövegét (javítja az összetett lekérdezések olvashatóságát), és növeli a sebességet (ha a lekérdezésben több helyen is használ ideiglenes táblaadatokat).

kötegelt kérések

A kötegelt lekérdezések logikailag kiegészítik az ideiglenes táblák funkcionalitását, és több lehetőséget biztosítanak a lekérdezésekkel végzett munka során.

A kötegelt lekérdezésben valójában több lekérdezést is leírhat, amelyek mind kapcsolódnak egymáshoz ideiglenes táblák segítségével, mind pedig nem kapcsolódnak egymáshoz (lehetséges, de nem világos, hogy miért?). Ennek eredményeként az összes lekérdezést szekvenciálisan végrehajthatja, és ennek eredményeként vagy egy tömböt kaphat az egyes lekérdezések végrehajtásának eredményeivel, vagy az utolsó lekérdezés eredményét. Ha lekérdezési eredményeket tartalmazó tömböt szeretne kapni, használja a metódust ExecutePackage() kérés objektumot, és megkapja az utolsó kérés eredményét ExecuteRequest().

A kérés szövegében a csomagkérelmeket ";" szimbólum választja el egymástól. (pontosvessző). Kötegelt lekérdezésenként csak egy virtuális tábla névtér található. Az ideiglenes táblakezelő használata nem kötelező, de lehetséges, ha ideiglenes táblákat szeretne átvinni egyik köteglekérdezésből a másikba.

Írjuk át az eljárást kötegelt lekérdezések használatára:

Feladáskezelési eljárás (hiba, feladási mód)

While Selection.Next() Loop

//Negatív egyenlegek ellenőrzése

// Áthalad a nyilvántartáson

EndCycle;

Vége eljárás

Valójában eltávolítottam a lekérdezési objektum definícióját és az ideiglenes táblakezelő használatát, kombináltam a lekérdezési szövegeket (ügyeljen a szövegek közötti ";" elválasztóra). Ennek eredményeként a lekérdezés szövege olvashatóbbá vált (és a lekérdezéskészítő használatakor a lekérdezés olvashatósága jelentősen javul).

A változóhoz intézett kérés végrehajtása után ArrayResults 3 elemünk van. Az első kettő egy számot tartalmaz, amely az ideiglenes táblákban elhelyezett rekordok számát jellemzi DocPMÉs Terméklista, a harmadik pedig mezőket tartalmaz Elnevezéstan, Doc_ Mennyiségés Reg_ Mennyiség.

változóba Eredmény kérése csak egy minta kerül bele.

Nos, ennyi a kötegelt kérésekhez. Nagyon kényelmes mechanizmus mind a lekérdezések írása, mind az összetett lekérdezések olvasása szempontjából.

Az 1C Enterprise platform lehetővé teszi, hogy egyszerre több lekérdezést hajtson végre egymás után. Az 1C-ben ezt kérések kötegének nevezik. Egy csomagon belül minden kérés "pontosvesszővel" van elválasztva.

A lekérdezések kötegben történő szakaszos végrehajtásához általában először ideiglenes táblákat hoznak létre, majd kialakítják azok közös használatának feltételeit, például szűrőket, összekapcsolásokat, csatlakozásokat. Ennek köszönhetően elkészül a végeredmény. A kötegben lévő bármely lekérdezés eredményeként kapott ideiglenes táblák a csomag egészének végrehajtásának végéig vagy az ideiglenes táblákat megsemmisítő lekérdezés végrehajtásáig fennmaradnak.

Ezenkívül a kötegelt lekérdezések és ideiglenes táblák használata nagymértékben javítja a kód teljes részének olvashatóságát. Az olyan összetett lekérdezéseket, amelyek beágyazott lekérdezéseket is tartalmaznak, nagyon nehéz megérteni. Ha azonban egy hosszú, összetett lekérdezést több részre bont, és még ideiglenes táblákat is használ, akkor ez nem csak az észlelést javítja, hanem a legtöbb esetben a teljesítmény növekedéséhez is vezet.

Egy másik fontos részlet a kötegelt kérések mellett az 1C-ben, hogy eltérően minden kérés eredményét kötegben kaphatjuk meg külön-külön.

Példa kérelmek kötegének létrehozására 1C nyelven

A lekérdezések köteg létrehozására vonatkozó példa megtekintéséhez a lekérdezéskészítőt fogjuk használni, amelyet az egyértelműség érdekében a lekérdezési konzolból hívunk meg. Így azonnal láthatjuk a csomag végrehajtásának eredményét.

Hozzunk létre egy egyszerű kötegelt kérést. Azt javaslom, hogy azonnal illessze be a kérés szövegét a -ba, majd nyissa meg, és nézze meg, hogyan épül fel a kéréscsomag. Adjon hozzá egy új kérést a konzolhoz, és illessze be a következő szöveget:

Ingyenes 267 1C videóleckéket kaphat:

Önhordó.Link,
Önfenntartó. Szülő,
Önhordó.Kód,
Önfenntartó.QuickChoice kód,
Önfenntartó. Név,
Önhordó. Megtekintés,
Önhordó, mérlegen kívüli,
Önfenntartó. Mennyiségi,
TÓL TŐL
Számlaterv Önfenntartó AS Önfenntartó
AHOL
Önfenntartó.Link = &Fiók
;
////////////////////////////////////////////////////////////////////////////////

KIVÁLASZTÁS
Self-supportingTypesSubconto.LineNumber AS LineNumber,
Önhordó subconto típusok. Alkontotípus AS Alkontotípus,
Önhordó típusú Subconto.Type of Subconto.Description AS név,
Self-supportingSubconto Types.Subconto Type.ValueType AS ValueType,
Self-supportingTypes of Subconto.Only Forgalom AS OnlyForgalom,
Self-supportingTypesSubconto.Sum AS Sum
TÓL TŐL
Számlatábla Önhordó A Subconto AS típusai Önhordó
AHOL
Self-supportingTypesSubconto.Reference = &Fiók
SORREND
Self-supportingTypesSubconto.LineNumber

Nálam ez így néz ki:

Most térjünk át a lekérdezéskészítőre. Itt a "Csomagigénylések" fülre leszünk kíváncsiak:

Amint látja, két kérésünk van. Bármelyikre duplán kattintva folytathatja a szerkesztését:

Nyomjuk meg az "OK" gombot, és próbáljuk megnézni a kötegelt lekérdezés eredményét.

Állítsa be a "Számla" paramétert. A Számlatervből bármelyik számlát kiválaszthatja. Amint azt valószínűleg már sejtette, ennek a kéréscsoportnak meg kell kapnia a fiók tulajdonságait. Kattintson a "Futtatás" gombra, és nézze meg az eredményt:

Az Execute() és az ExecutePackage() metódusok

Amikor a lekérdezésem annyira bonyolulttá vált, hogy túlszárnyalta a tudásomat, úgy döntöttem, hogy kötegelt lekérdezéseket használok.

De szembesülve azzal, hogy semmit sem tudok róluk. Kiderült, hogy minden nagyon egyszerű. 5 perc múlva már használhatja a kötegelt lekérdezéseket. Kezdje el olvasni.

Mint kiderült, minden nagyon egyszerű. Csak több lekérdezést kell írnia pontosvesszővel elválasztva. Az eredményt az utolsó kérésben küldjük vissza.

A kötegelt kérések csak a 8.1.11.67.4 verzióban jelentek meg.

Íme a kérés szövege:

SELECT T1.Zn PUT WTBletters FROM (VÁLASSZON "A" AS ZN COMBINE ALL SELECT "B") AS T1;

SELECT T1.Zn PUT WTCigures FROM (SELECT "1" AS Zn COMBINE ALL SELECT "2") AS T1;

TB.Zn, TTs.Zn, TB.Zn+TP.Zn KIVÁLASZTÁS A VTBletters AS TB, VTSigers AS TP közül

A kötegelt lekérdezéseket bármely normál lekérdezési konzol támogatja.

Az ábra egy lekérdezés-végrehajtási mintát mutat:

És most egy kicsit tapasztalatból. Miért van szükség kötegelt kérésekre?

A helyzet az, hogy néhány köztes eredményt elhelyezhet egy ideiglenes táblában, amelyre több további lekérdezésben szükség lehet.

Korábban, amikor nem voltak ideiglenes táblák, meg kellett másolnia a lekérdezés szövegét.

Természetesen megteheti kötegelt lekérdezés nélkül is több lekérdezés egymás utáni végrehajtásával és a beágyazott táblák manipulálásával. De kötegelt kérések esetén ez kényelmesebb. Csak ír egy lekérdezést, és nem gondol ideiglenes táblák elhelyezésére. Minden magától történik.

Ezen túlmenően, ha adatkompozíciós rendszert (DCS) használnak, az intelligensen kiválasztja a szükséges mezőket, és minimalizálja a lekérdezések teljes kötegét.

Ha a kéréseknek volt módszerük Request.Execute() most van egy módszer Request.ExecutePackage(), amely a köteg összes tábláját tömbként adja vissza.

A kötegelt kérések bejelentése az 1c honlapján itt található: http://v8.1c.ru/overview/release_8_1_11/#Functional

Történelem az életből

Hadd magyarázzam el, mi késztetett arra, hogy kötegelt kéréseket tegyek.

Tehát képzeld el, hogy van egy dokumentum, az van táblázatos rész. egy oszlopban" Hiba» jel, hogy nem történt-e hiba a bizonylat kitöltésekor. egy oszlopban" Szöveghibák» lehet egy vagy több mondat hibaszövegekkel. A mondatokban előforduló hibák típusai előre ismertek.

Tehát megadjuk az összes hiba listáját a táblázatban Hibakódok- tartalmazza a hibakódot és a keresési részstringet.

Minden sorhoz egy, kettő vagy több hibát kapunk. Mivel Egy sorban több hiba is lehet.

De előfordulhat, hogy a hibát nem ismeri fel, pl. zászló" Hiba” áll, de a hibaszöveg nem adott nekünk hibakódot.

Bal oldali összekapcsolást végzünk, ahol a hibakód NULL, megadjuk a " hibakódot Egyéb hibák» .

De a probléma az volt, hogy körülbelül 200 hibakód volt, így a bal kapcsolat nagyon sokáig működött. Ki kellett cserélnem egy belső csatlakozásra, ami repült. De ugyanakkor olyan vonalak is elvesztek, amelyeknél nem található a hiba. Még mindig nem tudtam rájönni, hogyan húzzam ezeket a vonalakat az eredménybe.

A lekérdezés a linkelő rendszerre íródott, azaz. értéktáblázatok vagy ideiglenes táblák elvileg nem használhatók. Itt jönnek jól a kötegelt kérések.

Egyszerűen újra összekapcsoltam az összes hibás sort azokkal a sorokkal, amelyeknél hibát találtak, és továbbra is hozzáadtam az "Egyéb hibák" típusú hibatípust.

A cikk leírja az 1C:Enterprise platformon megvalósított kötegelt kérések mechanizmusát. A cikk elolvasása után tudni fogja:

Mik azok a kötegelt kérések és mire szolgálnak?
Hogyan készítsünk lekérdezési csomagot a lekérdezéskészítővel?
Hogyan lehet eredménytömböt visszaadni egy köteg minden egyes kérésére?

Alkalmazhatóság

Az anyag az 1C:Enterprise platform jelenlegi verzióira vonatkozik, 8.3 kiadás

Kérelemcsomag célja

A platform lehetővé teszi a kérelmek kötegeinek kezelését. Lehetőséget kapunk több kérés "egyszerre" végrehajtására. A kötegelt kérésben a kérés szövegeit ";" szimbólum választja el egymástól. (pontosvessző).

A lekérdezések szekvenciálisan hajtódnak végre, míg a bármely lekérdezés végrehajtása során létrehozott ideiglenes táblák a teljes lekérdezéscsomag végrehajtásának végéig vagy az ideiglenes táblát megsemmisítő csomagban a lekérdezés végrehajtásáig léteznek. Fontos különbség beágyazott lekérdezésből az, hogy a csomag minden egyes lekérdezésének eredménye külön-külön elérhető.

A lekérdezési kötegekkel fokozatos lekérdezés-végrehajtást érhet el. Ehhez a kötegelt lekérdezésben először ideiglenes táblákat hozunk létre, majd megosztjuk azokat (csatlakozás, egyesülés, szűrők), hogy megkapjuk a lekérdezés végeredményét. Azt is fontos megjegyezni, hogy az ideiglenes táblák kötegelt lekérdezésekben való használata javítja a lekérdezés szövegének olvashatóságát.

Az egymásba csomagolt, egymásba ágyazott lekérdezéseket gyakran meglehetősen nehéz megérteni. De ha egy ilyen lekérdezést ideiglenes táblák segítségével írunk át, akkor a lekérdezés láthatósága jelentősen megnőhet. A lekérdezési csomag ideiglenes táblákkal való használata szintén javíthatja a lekérdezés teljesítményét.

Vannak olyan lekérdezésteljesítmény-optimalizálási technikák, amelyek a beágyazott lekérdezések ideiglenes táblákkal való helyettesítésén alapulnak.

Az ideiglenes tábla akkor lehet hasznos, ha ugyanazt az adatot többször kell használnia egy nagy lekérdezésben, például más táblákkal való összekapcsoláskor. Beágyazott lekérdezések használatakor az ilyen adatokat többször is be kellene szerezni ugyanazon beágyazott lekérdezések segítségével, ami természetesen mind a szöveg olvashatóságát, mind a teljesítményt befolyásolja.

Hozzon létre egy lekérdezési csomagot a konstruktor segítségével

A csomagban található külön kéréseket a szövegben ";" szimbólum választja el egymástól. (pontosvessző). A lekérdezés törzsének manuális felosztásának elkerülése érdekében használhatja a Lekérdezéskészítőt.
A lekérdezéskészítőnek külön lapja van a lekérdezési csomagokhoz. A kérések a parancssor megfelelő gombjával adhatók hozzá a csomaghoz, illetve mozgathatók felfelé vagy lefelé.

Egyedi lekérdezések vizuális megjelenítése - a konstruktor jobb oldalán található fülek, amelyekkel továbbléphet egy adott lekérdezés szövegének szerkesztéséhez. A nevek ezeken a lapokon jelennek meg az ideiglenes táblákhoz, az adatkiválasztási kérésekhez – „2. csomag kérés” stb., törléshez – „– NameVT”.

Az adatbázistáblák listájában is megjelennek az azon belül létrehozott ideiglenes táblák ezt a csomagot. Ez azonban nem jelenti azt, hogy az ideiglenes táblák az összes többi információsbázis táblával együtt az adatbázisban vannak tárolva.

Csomagkérések végrehajtása

Ha a tárgy Vizsgálat A kötegelt lekérdezés végrehajtásakor ideiglenes táblakezelő van telepítve, az ideiglenes táblák, amelyek nem semmisültek meg a kötegelt lekérdezés részeként, a telepített kezelőben lesznek elmentve.

A kötegelt lekérdezés szövegében lehetőség van olyan ideiglenes táblák használatára és megsemmisítésére, amelyek a köteg végrehajtásának indításakor a telepített ideiglenes táblakezelőben léteztek.

A módszeren kívül Végrehajtás(), amely szekvenciálisan végrehajtja a csomag összes kérését, és visszaadja a csomag utolsó kérésének eredményét, van még egy módszer a platformon - ExecutePackage().

Ez a metódus az összes lekérdezést sorrendben hajtja végre, és a csomagban lévő minden egyes lekérdezéshez egy eredménytömböt ad vissza, abban a sorrendben, ahogyan a lekérdezések megjelennek a csomag törzsében.

Az ideiglenes tábla megsemmisítésére irányuló kérelem végrehajtásának eredménye az érték Határozatlan, amely szintén az eredménytömbbe kerül.

Ez a cikk azoknak az olvasóknak szól, akik ismerik az SQL nyelvet.

Az 1C-ben a 8-as verzió óta használt lekérdezési nyelv mára azzá vált hasznos eszköz adatbázisokkal való munkavégzéshez, ami lehetővé teszi belőlük olvasását, de írását nem. Szintaktikailag a lekérdezési nyelv nagyon hasonlít az SQL nyelvhez, de oroszul.

Az alábbiakban a lekérdezési nyelv és az SQL fő operátorai közötti megfelelési táblázat látható:

1C lekérdezési nyelvi operátorok	SQL utasítás


KÜLÖNFÉLE



ÖSSZETETT
CSOPORTOSÍT
EGYESÜL
SORREND

És messze van teljes lista. Teljesebb háttér-információ tovább elérhető operátorok A lekérdezési nyelv a lekérdezéskészítőben érhető el, amelyről az alábbiakban lesz szó.

Kérés végrehajtása 1C tól programkód a „Request” beépített nyelvi objektum segítségével történik. Példa adatbázis-lekérdezés írására a beépített programozási nyelv használatával:

Request = Új kérés; Query.Text = "VÁLASZT | Synonym.Reference AS Reference |FROM | Catalog.Directory1 AS Szinonim"; Selection = Query.Execute().Select(); While Selection.Next() Loop // Kijelölés feldolgozás beszúrása SelectionDetailRecords Cikk vége;

Az "Execute" metódus végrehajtja a lekérdezést, a "Select" metódus "SelectionFromQueryResult" típusú értéket ad vissza. Használhatja az Unload metódust is, amely egy értéktáblázatot ad vissza.

A lekérdezési paraméterek a "Parameters" tulajdonságban tárolódnak (jelen esetben egy szerkezetről van szó, tehát itt a struktúra összes metódusa alkalmazható - beszúrás, törlés stb.).

Példa a "Query.Parameters.Insert" paraméter beállítására ("Directory", ReferenceReference). A lekérdezésben a paramétereket az „&Reference” jellel érheti el. Alább látható egy példa kérés paraméterek használatával:

Request = Új kérés; Query.Text = "SELECT | Users.Reference AS Link, | Users.Parent AS Parent, | Users.Name AS név |FROM | Directory.Users AS Users |WHERE | Users.Reference = &Directory"; Query.Parameters.Insert("Katalógus", DirectoryReference); Selection = Query.Execute().Select(); While Selection.Next() Loop // Kijelölés feldolgozás beszúrása SelectionDetailRecords Cikk vége;

Emlékezzünk vissza, hogy a lekérdezési nyelv csak az adatbázisból származó adatok olvasására szolgál, ezért nem rendelkezik az ilyen lekérdezések analógjaival. SQL utasítások mint az INS ERT és az UPDATE. Az adatok csak a következőn keresztül módosíthatók tárgymodell beépített programozási nyelv 1C. Ezenkívül az 1C lekérdezési nyelvben vannak olyan operátorok, amelyeknek nincs analógja az SQL-ben, például:

A HIERARCHIÁBAN
PUT
INDEX BY

A HIERARCHIÁBAN– lehetővé teszi a hierarchikus szótár összes olyan elemének kiválasztását, amely az átadott hivatkozás hierarchiájában szerepel. Minta kérés segítségével A HIERARCHIÁBAN:

VÁLASZTÁSA Termékek.Link, Termékek.Cikk a címtárból.Termékek AS Termékek WHERE Termékek.Link A HIERARCHIABAN (&Citrus)"

Ebben az esetben a Citrus nómenklatúra katalógusának összes alárendelt eleme visszakerül az eredményhez, függetlenül attól, hogy a katalógus hány hierarchiaszinttel rendelkezik.

Szintén a feladat például egy "Pen" nevű termék megtalálása. A terméknek szerepelnie kell az „Irodószerek. Áruk”, vagyis nem kell kilincset keresnünk. A nómenklatúra felépítése ebben az esetben a következő:

hivatal

kiegészítők

|_ Kilincsek |_ Egyszerű ajtókilincs |_ Luxus kilincs

Ilyen lekérdezést írunk:

SELECT Áruk.Link, áruk.cikk FROM Directory.Goods AS Goods WHERE Áruk.Név Hasonló: "Pen%" And Goods.Link IN HIERARCHY(&Office)"

A szerkezet használatakor A HIERARCHIÁBAN ne feledje, hogy ha üres hivatkozást ad át az „Office” paraméterre, akkor a kérés végrehajtása lelassul, mivel a platform minden elemet ellenőriz, hogy a gyökérhez tartoznak-e.

PUT– Ez az állítás az eredményt egy ideiglenes táblázatba helyezi. Példa kérésre:

SELECT Users.Reference AS Reference, Users.Parent AS Parent, Users.Name AS Name PUT SelectedUsers FROM Directory.Users AS Users WHERE Users.Reference = &Directory; SELECT SelectedUsers.Reference AS Link, SelectedUsers.Parent AS Parent, SelectedUsers.Name AS név FROM SelectedUsers AS SelectedUsers

Ezt az SQL-lekérdezést több lekérdezés hajtja végre:

Ideiglenes tábla létrehozása (a platform "újra felhasználhatja" a korábban létrehozott ideiglenes táblákat, így a létrehozás nem mindig történik meg);
Adatok elhelyezése egy ideiglenes táblában;
A fő lekérdezés, nevezetesen a SEL ECT végrehajtása ebből az ideiglenes táblából;
Az ideiglenes asztal megsemmisítése/eltakarítása.

Egy ideiglenes tábla kifejezetten megsemmisíthető a konstrukcióval ELPUSZTÍTANI, vagy implicit módon - az ideiglenes táblakezelő bezárásakor.

A beépített programozási nyelv "Request" objektuma rendelkezik a "TemporaryTable Manager" tulajdonsággal, amelyet úgy terveztek, hogy ideiglenes táblákkal működjön. Példa a kódra:

MBT = NewTempTableManager(); Request = Új kérés; Query.TemporaryTable Manager = MBT;

Egy lekérdezés végrehajtása után az MBT változó másodszor is felhasználható egy másik lekérdezésben, ami kétségtelenül további előnye az ideiglenes táblák használatának. Ebben az esetben a „Bezárás” metódus meghívásakor az ideiglenes tábla törlődik az adatbázisból…

MVT.Close();

...vagy változó memóriából való törlésekor, vagyis annak a metódusnak a végrehajtásakor, amelyben a változót deklarálták. Az ideiglenes táblák növelik a lemezalrendszer terhelését, ezért ne hozzon létre túl sok ideiglenes alrendszert (például hurokban) vagy nagy alrendszert.

INDEX BY– ezt az operátort a kezelővel együtt használják PUT. Ideiglenes tábla létrehozásakor ez az operátor indexelni tudja a létrehozott táblát, ami jelentősen felgyorsítja a vele való munkát (de csak akkor, ha az index egyezik a lekérdezéssel).

Ingyenes szakértői tanácsadás

Köszönjük a visszajelzést!

Az 1C szakembere 15 percen belül felveszi Önnel a kapcsolatot.

Néhány lekérdező nyelvi operátor jellemzői

VÁLTOZÁSRA – adott operátor egy adott lekérdezési tábla (vagy a lekérdezésben részt vevő összes tábla) zárolására szolgál. A zárás U-zár elhelyezésével történik az asztalon. Az SQL-ben ez az UPDLOCK tippen keresztül valósul meg. Ez a konstrukció a holtpontok elkerülése érdekében szükséges. Példa egy konstrukcióval rendelkező lekérdezésre VÁLTOZTATÁSRA:

SELECT Users.Reference AS Link, Users.Parent AS Parent, Users.Name AS Name FROM Directory.Users AS Users

BAN BEN ezt a példát U A zár a „Felhasználók” asztalra kerül. Ha nem ad meg zárolandó táblát, az a lekérdezésben részt vevő összes táblára rá lesz kényszerítve. Fontos megjegyezni, hogy ez a konstrukció csak olyan konfigurációkban működik, amelyekben a automatikus mód blokkoló kezelés.

ÖSSZETETT- a lekérdezés támogatja a kapcsolatokat BAL/JOBB, TELJES, BELSŐ, ami az SQL-ben a csatlakozásoknak felel meg - LEFT/RIGHT JOIN, OUTER JOIN, INNER JOIN.

A lekérdezéskészítő használatakor azonban ezt nem fogja tudni megtenni JOBB CSATLAKOZÁS. A konstruktor egyszerűen felcseréli a táblákat, de az operátor mindig marad. Emiatt az 1C-ben soha nem fogja megtalálni a megfelelő csatlakozás használatát.

Szintaktikailag a kapcsolat így néz ki:

SELECT Table1.Reference AS Reference FROM Reference.Reference1 AS Table1 LEFT JOIN Reference.Reference2 AS Table2 BY Table1.Attributes = Table2.Attributes

Az 1C lekérdezési nyelvnek nincs operátora a derékszögű termékhez való csatlakozáshoz (CROSS JOIN). Az operátor hiánya azonban nem jelenti azt, hogy a lekérdezési nyelv nem támogatja az ilyen összekapcsolást. A táblázatokat szükség esetén az alábbi módon lehet összeilleszteni:

SELECT Table1.Reference AS Reference FROM Reference.Reference1 AS Table1 LEFT JOIN Reference.Reference2 AS Table2 ON IGAZ

Amint a példából látható, a csatlakozási kulcs be van állítva IGAZBAN, vagyis az egyik táblázat minden sora egy másik sorának felel meg. Az összekapcsolás típusa (LEFT, RIGHT, FULL, INNER) nem számít, ha mindkét táblában vannak sorok, de ha valamelyik táblában nincsenek sorok (elengedjük a táblát), az eredmény más lesz. Például használat közben BELSŐ a kapcsolat eredménye üres lesz. Használata BAL JOBB az összekapcsolás vagy nem eredményez adatokat, attól függően, hogy adatokat tartalmazó táblát egyesítünk-e vagy sem. Használata TELJES kapcsolati adatok mindig lesznek (természetesen csak az egyik tábla, mivel a másik üres), a kapcsolat típusának megválasztása az adott alkalmazásfeladattól függ.

Egy kis vizuális nyom, hogyan működnek különböző típusok csatlakozások:

TETSZIK. A hasonló kezelővel ellentétben SQL nyelv– LIKE, sablon ehhez TETSZIK csak néhány speciális karakter használatával adható meg:

% (százalék): tetszőleges számú karaktert tartalmazó sorozat;
_ (aláhúzás): egy tetszőleges karakter;
/ - a következő karaktert szabályos karakterként kell értelmezni.

EREDMÉNYEK BE az SQL megfelelője a ROLLUP operátor. Példa az operátor használatára EREDMÉNYEK:

KIVÁLASZTÁS KIVÁLASZTÁSA Áruk.Ár AS Ár, Áru.Tétel AS Áru A címtárból.Nómenklatúra AS Áru EREDMÉNYEK ÁTLAG(ÁRA) Áruk szerint

Az eredmény a következő lesz:


Ágy	9833,333



Vas





Toll

Ez azt jelenti, hogy az eredményhez egy további sor kerül, amely tartalmazza annak a mezőnek az értékét, amelyen a csoportosítás történik, és az összesítő függvény értékét.

A kötegelt kérések kezelése

Az 1C lehetővé teszi a kérelmek kötegeinek kezelését. A kötegelt kérésben a kérés szövegei pontosvesszővel (;) vannak elválasztva. Az 1C kötegkérés végrehajtása szekvenciálisan történik. Példa kötegelt kérés szövegére:

SELECT Users.Link AS Link, Users.Parent AS Parent, Users.Name AS név FROM Directory.Users AS Users;
SELECT Munkaütemezés.Felhasználó AS felhasználó, Munkaütemezés.Dátum AS Dátum, Munkaütemezés Munkaóra AS Munkaóra Adatnyilvántartásból Munkaütem AS Munkaütemezés

A csomagban található összes kérés eredményének eléréséhez az "ExecutePackage" kérési objektum metódusát kell használnia az "Execute" helyett. Ez a módszer sorban hajtja végre az összes kérést. A lekérdezés eredménye a csomagból származó egyes lekérdezések eredményeinek tömbje, és a tömbben lévő sorrend megegyezik a csomag törzsében lévő lekérdezések sorrendjével.

A lekérdezés nyelvét tekintve érdemes megemlíteni egy olyan szolgáltatást, mint a virtuális táblák. A virtuális táblák nem jelennek meg az adatbázisban; ez egyfajta burkoló, amely a DBMS oldalon lekérdezésként, allekérdezések segítségével fut le. Példa egy 1C lekérdezésre virtuális táblákat használva:

KIVÁLASZTÁS Kötelezettségek nyilvántartása Forgalom. Kötelezettségek AS Kötelezettsége Felhalmozási Nyilvántartásból. Kötelezettségnyilvántartás. Forgalmak() AS Kötelezettségek Nyilvántartása Forgalom

Egy ilyen lekérdezés a DBMS-hez így fog kinézni:

SEL ECT T1.Fld25931RRef FR OM (SELECT T2._Fld25931RRef AS Fld25931RRef, CAST(SUM(T2._Fld25936) AS NUMERIC(38, 8)) AS Fld25936Forgalom(_SERIUM_, T AS.8)3, CAST.8, AS Fld25937Forgalom_ FR OM dbo._AccumRgTn25938 T2 WH ERE ((T2._Fld949 = @P1)) AND ((T2._Fld25936 @P2 VAGY T2._Fld25937 B.H.25937 B.H. ) ) AS NUMERIC(38, 8))) 0.0 VAGY (CAST(SUM(T2._Fld25937) AS NUMERIC(38, 8))) 0.0) T1>>>>

Látható, hogy nem úgy néz ki, mint az SQL, hiszen van egy részlekérdezés, egy csoportosítás. A virtuális táblák általában "szintaktikai cukrok", vagyis általában a lekérdezések fejlesztésének kényelmét szolgálják, hogy a lekérdezések kompaktabbak és olvashatóbbak legyenek.

Csak a regiszterek rendelkeznek virtuális táblákkal, de a lekérdezéskészítőben megtekinthető, hogy egy regiszterhez mely virtuális táblák állnak rendelkezésre.

Virtuális táblák használatakor mindig meg kell adni egy kiválasztási feltételt. Ellenkező esetben teljesítménybeli problémák léphetnek fel.

A kérelem törzsében így néz ki:

Felhalmozási nyilvántartás.RegisterLiabilities.Turnovers(, Operation = &Operation) AS RegisterObligationsForgalom

A lekérdezések írásának, vagyis a lekérdezési szövegek létrehozásának kényelme érdekében az 1C-ben van egy konstruktor, amely a helyi menün keresztül hívható meg (jobb gombbal):

A Lekérdezéskészítőben megtekintheti a támogatott lekérdezési nyelvi funkciók és operátorok teljes listáját.

A Query Builder egy nagyon rugalmas vizuális eszköz bármilyen bonyolultságú lekérdezés létrehozásához. Csak konfigurátor módban érhető el. Vállalati módban van egy úgynevezett "lekérdezési konzol" - ez az külső feldolgozás az ITS lemezen található. Felügyelt alkalmazás esetén a kéréskonzol letölthető a saját.1c.ru webhelyről.

A munka leírása a lekérdezéskészítőben túlmutat e cikk keretein, ezért nem foglalkozunk vele részletesen.

A szuboptimális lekérdezési teljesítmény okai

Az alábbiakban felsoroljuk azokat a főbb okokat (de nem mindegyiket), amelyek a lekérdezés lassú végrehajtásához vezetnek.

Csatlakozás használata segédlekérdezésekkel

Allekérdezésekkel nem ajánlott csatlakozni, az allekérdezéseket ideiglenes táblákkal kell helyettesíteni. Az allekérdezések összekapcsolása jelentős teljesítménycsökkenéshez vezethet, míg a lekérdezések végrehajtásának sebessége különböző DBMS-eken jelentősen eltérhet. Az ilyen lekérdezések végrehajtási sebessége szintén érzékeny a DBMS-ben lévő statisztikákra. Ennek az az oka, hogy a DBMS optimalizáló nem mindig tudja helyesen meghatározni az optimális lekérdezés végrehajtási tervet, mivel az optimalizáló semmit nem tud arról, hogy a lekérdezés hány sort ad vissza a végrehajtása után.

Virtuális táblák használata Query Joins során

A DBMS-szintű virtuális táblák segédlekérdezésekként kerülnek végrehajtásra, így az okok ugyanazok, mint az első bekezdésben.

Olyan feltételek használata egy lekérdezésben, amelyek nem egyeznek a meglévő indexekkel

Ha a lekérdezési feltételekben (az operátorban AHOL vagy virtuális tábla feltételek mellett) olyan mezőket használ, amelyek nem mindegyike szerepel az indexben, adott kérést végezni fog SQL használatával táblázat- vagy indexvizsgálati konstrukciók (teljesen vagy részben). Ez nem csak a lekérdezés végrehajtási idejét érinti, hanem a túlzott S-zárolást is az extra sorokon, ami viszont a zárolás eszkalációjához vezethet, vagyis a teljes tábla zárolásra kerül.

VAGY használata a lekérdezési feltételekben

Használat logikai operátor VAGYépítés alatt AHOL táblázat vizsgálatot is eredményezhet. Ez annak a ténynek köszönhető, hogy a DBMS nem tudja megfelelően használni az indexet. Ahelyett VAGY konstrukció alkalmazható ÖSSZE ÖSSZETÉTEL.

Adatok lekérése ponton keresztül összetett típusú mezőkhöz

Nem ajánlott ponton keresztül értékeket fogadni (a szerkezetben VÁLASSZA HOL), mert ha az objektum attribútum összetett típusú, akkor az összekapcsolás minden ebbe az összetett típusba tartozó táblával megtörténik. Ennek eredményeként a DBMS-nek történő lekérdezés jelentősen bonyolultabb lesz, ami megakadályozhatja, hogy az optimalizáló a megfelelő lekérdezés-végrehajtási tervet válassza ki.