1s lekérdezés rendezés dokumentumtípus szerint. A nagy kérések kis trükkjei

Az 1C platformon az adatbázistáblák lekérdezésének kialakításához és végrehajtásához egy speciális programozási nyelv objektumot használnak. Kérés. Ez az objektum a konstrukció meghívásával jön létre Új kérés. Kényelmes a lekérdezés használata, ha összetett adatok gyűjtésére van szükség, szükség szerint csoportosítva és rendezve. A lekérdezés használatának klasszikus példája a felhalmozási regiszter állapotának összefoglalása egy adott időpontban. Ezenkívül a lekérdezési mechanizmus megkönnyíti az információszerzést a különböző időszakokban.

A kérés szövege az az utasítás, amely szerint a kérést végre kell hajtani. A kérelem törzse a következőket írja le:

lekérdezési adatforrásként használt infobase táblák;
a lekérdezésben feldolgozandó táblamezők;
csoportosítási szabályok;
eredmények rendezése;
stb.

Az utasítás egy speciális nyelven - a lekérdező nyelven - van összeállítva, és különálló részekből áll - szakaszokból, mondatokból, kulcsszavakból, függvényekből, aritmetikai és logikai operátorokból, megjegyzésekből, konstansokból és paraméterekből.

Az 1C platform lekérdezési nyelve nagyon hasonlít más SQL nyelvek szintaxisához, de vannak különbségek. A beépített lekérdező nyelv fő előnyei: mezőhivatkozás, virtuális táblák, kényelmes munkavégzés az összesítéssel, gépeletlen mezők a lekérdezésekben.

enum értékek;
előre meghatározott adatok:
könyvtárak;
a jellemzők típusainak tervei;
számlatáblázatok;
számítási típusok tervei;
üres hivatkozások;
üzleti folyamatok útpontjainak értékei.

A kérelem szövege tartalmazhat olyan rendszerfelsorolási értékeket is, amelyek hozzárendelhetők az adatbázistáblák mezőihez: AccumulationMotionType, AccountType és AccountingMovementType. A kérések előre definiált konfigurációs adatokra és rendszerfelsorolási értékekre vonatkoznak, függvénytípus literál használatával JELENTÉS. Ez a literál javítja a lekérdezés olvashatóságát és csökkenti a lekérdezési paraméterek számát.

Példa a literál használatára JELENTÉS:
WHERE város = ÉRTÉK (Könyvtár. Városok. Moszkva)
WHERE Város = ÉRTÉK (Reference.Cities.EmptyReference)
WHEREItemType = ÉRTÉK(Felsorolás.Terméktípusok.Szolgáltatás)
WHEREMovementType = ÉRTÉK(MovementTypeAccumulation.Income)
WHERE RoutePoint = ÉRTÉK(üzleti folyamat.üzleti folyamat1.útpont.művelet1

2) Az utasítások használata AUTOMATIKUS RENDELÉS egy lekérdezésben a lekérdezés végrehajtási ideje nagyon hosszú lehet, ezért ha nincs szükség rendezésre, akkor jobb, ha egyáltalán nem használjuk. A legtöbb esetben a rendezés alkalmazásának legjobb módja az utasítás RENDEZÉS.

Az automatikus elrendezés a következő elvek szerint működik:

Ha a lekérdezésben az ORDER BY záradékot adtuk meg, akkor ebben a tagmondatban minden táblára való hivatkozást felváltanak azok a mezők, amelyek alapján a táblázat alapértelmezés szerint rendezve van (könyvtáraknál ez a kód vagy név, dokumentumoknál a dátum dokumentum). Ha a rendezési mező egy hierarchikus könyvtárra hivatkozik, akkor a rendszer e könyvtár szerint hierarchikus rendezést alkalmaz.
Ha a lekérdezésben nincs ORDER BY záradék, de van TOTALS záradék, akkor a lekérdezés eredménye a BY kulcsszó után a RESULTS záradékban található mezők szerint lesz rendezve, ugyanabban a sorrendben, és ha az összegeket a a mezők - hivatkozások, majd alapértelmezés szerint a hivatkozott táblák rendezési mezői alapján.
Ha a lekérdezésben nincsenek ORDER BY és TOTAL záradékok, de van GROUP BY záradék, akkor a lekérdezés eredménye a mondatban szereplő mezők szerint lesz rendezve ugyanabban a sorrendben, és ha a csoportosítás mezők szerint történt - hivatkozásokat, majd alapértelmezés szerint rendezi azokat a mezőket, amelyekre hivatkoztak.
Ha a lekérdezés nem tartalmazza a záradékokat és az ORDER BY, TOTAL és GROUP BY, akkor az eredmény a lekérdezésben megjelenő táblák alapértelmezett rendezési mezői szerint lesz rendezve.

Ha a lekérdezés tartalmazza a TOTAL záradékot, akkor az összegek minden szintjét külön-külön rendezik.

3) Annak érdekében, hogy elkerüljük az adatbázis újbóli lekérdezését, amikor a lekérdezés eredményét megjelenítjük a felhasználónak (például lekérdezés összeállítása vagy a lekérdezés eredményének megjelenítése táblázatos dokumentum használatával), hasznos az utasítás használata BEMUTATÓLINKEK A, amely lehetővé teszi egy referenciaérték megjelenítését.

Lehetőség van az utasítás használatára is TELJESÍTMÉNY- úgy tervezték, hogy egy tetszőleges típusú érték karakterlánc-reprezentációját kapja. A különbség ezen utasítások között az, hogy az első esetben, ha az utasítások hivatkozást adnak át, akkor az eredmény egy karakterlánc lesz, míg a többi esetben az átadott paraméter értéke lesz az eredmény. A második esetben az utasítás eredménye mindig egy karakterlánc lesz!

4) Ha a lekérdezés összetett típusú mezőt tartalmaz, akkor az ilyen mezőknél szükségessé válik a mezőértékek egy adott típusba öntése az utasítás segítségével EXPRESSZ, amely lehetővé teszi a felesleges táblák eltávolítását a bal oldali kapcsolatból egy összetett adattípusú mezővel, és felgyorsítja a lekérdezést.

Példa:
Az árumaradványok felhalmozására létezik egy nyilvántartás, amelyben a Nyilvántartó mező összetett típusú. Az igénylésben az Áruátvételi bizonylatok kelte és száma kerül kiválasztásra, míg a bizonylat adatainak a Nyilvántartó mezőn keresztül történő elérése nem eredményez sok bal oldali kapcsolatot a felhalmozási nyilvántartás táblájában a nyilvántartási bizonylatok tábláival.

VÁLASZT
EXPRESS(Árumaradványok. Nyilvántartó AS dokumentum. Áruk átvétele). Szám AS nyugtaszám,
EXPRESS(Árumaradványok. Nyilvántartó AS dokumentum. Áruk átvétele). Dátum AS Átvétel dátuma
TÓL TŐL
Felhalmozási nyilvántartás. Árumaradékok AS Árumaradékok

Ha egy típusöntés nem tekinthető megvalósíthatónak, akkor a típusöntés eredménye NULL lesz.

5) Ne felejtse el az utasításokat ENGEDÉLYEZVE, ami azt jelenti, hogy a lekérdezés csak azokat a rekordokat választja ki, amelyekhez az aktuális felhasználó rendelkezik engedélyekkel. Ha ez a szó nincs megadva, akkor abban az esetben, ha a lekérdezés olyan rekordokat választ ki, amelyekhez a felhasználónak nincs joga, a lekérdezés hibával fog működni.

6) Ha a lekérdezés uniót használ, és az unió egyes részein vannak beágyazott táblák (táblázatos résszel rendelkező dokumentum), és néhány esetben nincs szükség a kiválasztási lista mezőkkel történő kiegészítésére - üres beágyazott táblázatok. Ez a kulcsszó használatával történik KIÜRÍTHETŐ, amely után zárójelben jelennek meg azon mezők álnevei, amelyekből a beágyazott táblázat fog állni.

Példa:
// Válassza ki a Szám és az Összetétel mezőket
// virtuális táblából Document.Invoice
VÁLASSZA KIVÁLASZTÁSI SZÁMOT, KIÜRÍTHETŐ.(Nv, Tov, Menny.) ÖSSZETÉTELÉNEK
FROM Bizonylat.Számla
EGYESÍTSÜK MINDENT
SELECT Link.Number, Összetétel. (Sorszám, Termék, Mennyiség)
FROM Dokumentum.Számla bizonylat.Számla.Összetétel.*
7) Annak érdekében, hogy elkerülje az ismétlődő sorokat a lekérdezés eredményében, használja az utasítást KÜLÖNFÉLE, mert egyre világosabb, és az utasítás CSOPORTOSÍT aggregált függvények segítségével történő csoportosításhoz használják. Amúgy aggregált függvények használatakor a mondat CSOPORTOSÍT előfordulhat, hogy egyáltalán nem adható meg, miközben az összes lekérdezés eredménye egyetlen sorba kerül csoportosításra.

Példa:
// Ki kell deríteni, hogy mely szerződő felek
// az árut az időszakra szállították.
Válassza a Különféle lehetőséget
Bizonylat.Számla.Vállalkozó

8) Utasítás CSOPORTOSÍT lehetővé teszi a legfelső szintű mezők elérését anélkül, hogy az eredményeket ezek alapján csoportosítaná, ha összesítő függvényeket alkalmaznak egy beágyazott tábla mezőire. Bár az 1C súgójában meg van írva, a lekérdezési eredmények csoportosítása során az összesített függvényeket fel kell tüntetni a kiválasztási mezők listájában, és az összesítő függvények mellett csak azokat a mezőket lehet feltüntetni a listában, amelyekkel a csoportosítás történik. mezőket.

Példa:
VÁLASZT
Áruk és szolgáltatások átvétele. Áruk. (SUM (mennyiség), nómenklatúra),
Áruk és szolgáltatások átvétele. Link,
Áruk és szolgáltatások átvétele. Ügyfél
TÓL TŐL
Dokumentum Áruk és szolgáltatások átvétele AS Áruk és szolgáltatások átvétele
CSOPORTOSÍT
Áruk és szolgáltatások átvétele. Áruk. (Nómenklatúra)

9) Utasítás NULLA célja, hogy a NULL értéket egy másik értékre cserélje, de ne felejtse el, hogy a második paraméter az első típusává lesz konvertálva, ha az első paraméter típusa karakterlánc vagy szám.

10) A főtáblára hivatkozva a feltételben az alárendelt tábla adataira lehet hivatkozni. Ezt a szolgáltatást egy résztábla mezőire való hivatkozás megszüntetésének nevezik.

Példa (egy adott terméket tartalmazó dokumentumok keresése a táblázatos részben):
VÁLASZT
Bejárat.Link
TÓL TŐL
Document.Incoming Where Incoming.Goods.Nomenclature = &Nómenklatúra.

Ennek a lekérdezésnek az az előnye az Incoming.Products altáblázat lekérdezésével szemben, hogy ha a dokumentumokban ismétlődők vannak, a lekérdezés eredménye csak egyedi dokumentumokat ad vissza a kulcsszó használata nélkül. KÜLÖNFÉLE.

11) Érdekes operátori lehetőség BAN BEN egy rendezett halmaz előfordulásának ellenőrzése az ilyen halmazok halmazában (Mező1, Field2, ... , FieldN) In (Mező1, Field2, ... , FieldN).

Példa:
VÁLASZT
Vállalkozók.Link
AHOL
(Vállalkozók.Link, Áruk.Link)
(SELECT Sales.Customer, Sales.Product
Felhalmozási nyilvántartásból. Sales AS Sales)
TÓL TŐL
Címtár. Partnerek,
Címtár.Termékek

12) Amikor csak lehetséges, használja virtuális asztalok kéréseket. Lekérdezés létrehozásakor a rendszer számos virtuális táblát biztosít adatforrásként - ezek olyan táblák, amelyek egyben egy lekérdezés eredménye is, amelyet a rendszer a megfelelő kódszakasz végrehajtásakor generál.

A fejlesztő önállóan beszerezheti ugyanazokat az adatokat, amelyeket a rendszer virtuális táblaként biztosít számára, azonban az adatok megszerzésére szolgáló algoritmus nem lesz optimalizálva, mert:

Minden virtuális tábla paraméterezett, azaz a fejlesztőnek lehetősége van beállítani néhány paramétert, amelyeket a rendszer a virtuális tábla létrehozására vonatkozó kérés generálásakor fog használni. Attól függően, hogy a fejlesztő milyen virtuális tábla paramétereket adott meg, a rendszer KÜLÖNBÖZŐ lekérdezéseket generálhat, hogy ugyanazt a virtuális táblát kapja, és ezek az átadott paraméterek szempontjából optimalizálva lesznek.
A fejlesztőnek nem mindig van lehetősége hozzáférni azokhoz az adatokhoz, amelyekhez a rendszer hozzáfér.

13) Kliens-szerver üzemmódban a funkció SUBSTRING() az SQL Server adatbázis-kiszolgálónak átadott megfelelő SQL utasítás SUBSTRING() függvényével valósítjuk meg, amely összetett szabályok szerint számítja ki a SUBSTRING() függvény eredménytípusát a paraméterei típusától és értékétől függően, valamint attól függően, hogy milyen környezetben használják. A legtöbb esetben ezek a szabályok nem befolyásolják a lekérdezés végrehajtását, de vannak esetek, amikor az SQL Server által kiszámított eredmény karakterlánc maximális hossza elengedhetetlen a lekérdezés végrehajtásához. Fontos szem előtt tartani, hogy bizonyos esetekben a SUBSTRING() függvény használatakor az eredmény maximális hossza megegyezhet egy korlátozott hosszúságú karakterlánc maximális hosszával, amely 4000 karakter az SQL Serverben. Ez váratlan összeomláshoz vezethet a lekérdezés végrehajtása során:
Microsoft OLE DB Provider for SQL Server: Figyelmeztetés: A lekérdezésfeldolgozó nem tudott lekérdezési tervet előállítani az optimalizálóból, mert a GROUP BY vagy ORDER BY záradékban lévő összes oszlop teljes hossza meghaladja a 8000 bájtot.
HRESULT=80040E14, SQLSTATE=42000, natív=8618
A hiba elkerülése érdekében nem javasolt a SUBSTRING() függvény használata a korlátlan hosszúságú karakterláncok korlátozott hosszúságú karakterláncokká alakítására. Ehelyett jobb az EXPRESS() cast operátort használni.

14) Óvatosan használja VAGY a WHERE konstrukcióban, mivel egy OR-val rendelkező feltétel használata jelentősen "nehezítheti" a lekérdezést. A CONNECT ALL konstrukcióval megoldhatja a problémát.

Példa:
VÁLASZT

TÓL TŐL

AHOL
_DemoContractors.Link = &Link1

EGYESÍTSÜK MINDENT

VÁLASZT
_Demo Counterparties.NameFull
TÓL TŐL
Directory._DemoContractors HOGYAN _DemoContractors
AHOL
_DemoContractors.Link = &Link2

15) Állapot NEM BENT a WHERE konstrukcióban megnöveli a lekérdezés végrehajtási idejét, mivel ez egyfajta NOT (OR1 OR2 ... ORn), ezért nagy táblák esetén próbáljon meg egy LEFT JOIN-t használni az IS NULL feltétellel.

Példa:
VÁLASZT
_DemoContractors.Link
TÓL TŐL
Directory._DemoContractors HOGYAN _DemoContractors
LEFT JOIN Document._DemoBuyerOrder AS _DemoBuyerOrder
Szoftver _DemoContractors.Link = _BuyerDemoOrder.Contractor
AHOL
_Buyer's DemoOrder.Counterparty IS NULL

15) Használatkor Ideiglenes asztalok ezekben a táblákban indexelni kell a feltételt és összekapcsolni a mezőket, DE indexek használatakor a lekérdezés még lassabban futhat. Ezért szükséges minden indexes és index nélküli lekérdezést elemezni, mérni a lekérdezés végrehajtási sebességét és meg kell hozni a végső döntést.
Ha adatokat helyez el egy ideiglenes táblába, amelyet kezdetben egyes mezők indexelnek, akkor ezeken a mezőkön többé nem lesz index az ideiglenes táblában.

16) Ha nem használja Temp táblázatkezelő, akkor nem kell kifejezetten törölni az ideiglenes táblát, az a kötegelt lekérdezés befejezése után törlődik, ellenkező esetben az ideiglenes táblát az alábbi módok egyikén kell törölni: a lekérdezésben a DELETE paranccsal hívjuk meg a TemporaryTable-t. Manager.Close() metódus.

A lekérdezési nyelv az 1C 8.3 egyik alapvető mechanizmusa a fejlesztők számára. A lekérdezések segítségével gyorsan hozzáférhet az adatbázisban tárolt adatokhoz. Szintaxisa nagyon hasonlít az SQL-hez, de vannak eltérések.

Az 1C 8.3 (8.2) lekérdező nyelv fő előnyei az SQL-lel szemben:

referenciamezők hivatkozásának megszüntetése (egy vagy több pont tárgyattribútummá alakítása);
nagyon kényelmes az eredményekkel dolgozni;
virtuális táblák létrehozásának képessége;
a kérelmet angolul és oroszul is meg lehet írni;
az adatok blokkolásának képessége a holtpontok elkerülése érdekében.

A lekérdezési nyelv hátrányai az 1C-ben:

az SQL-től eltérően az 1C lekérdezések nem teszik lehetővé az adatok megváltoztatását;
a tárolt eljárások hiánya;
a karakterlánc számmá alakításának lehetetlensége.

Tekintse meg mini oktatóanyagunkat az 1C lekérdező nyelv alapvető konstrukcióiról.

Tekintettel arra, hogy az 1C kérések csak adatok fogadását teszik lehetővé, minden kérésnek a „SELECT” szóval kell kezdődnie. A parancs után megjelennek azok a mezők, amelyekből adatokat szeretne kapni. Ha „*”-t ad meg, akkor az összes elérhető mező ki lesz jelölve. A "FROM" szó után megjelenik az a hely, ahonnan az adatok kiválasztásra kerülnek (dokumentumok, nyilvántartások, címtárak stb.).

Az alábbi példában a teljes nómenklatúra nevei a "Nómenklatúra" referenciakönyvből vannak kiválasztva. A „HOGYAN” szó után a táblázatok és mezők álnevei (nevei) láthatók.

VÁLASZT
Nomenklatúra.Név AS NévNómenklatúra
TÓL TŐL
Címtár Nomenklatúra AS Nómenklatúra

A "SELECT" parancs mellett kulcsszavakat adhat meg:

KÜLÖNFÉLE. A lekérdezés csak azokat a sorokat jelöli ki, amelyek legalább egy mezőben különböznek egymástól (ismétlődések nélkül).
ELSŐ n, Ahol n– a sorok száma a kiválasztandó eredmény elejétől számítva. Leggyakrabban ezt a konstrukciót a válogatással együtt használják (ORDER BY). Például amikor dátum szerint ki kell választania bizonyos számú legújabb dokumentumot.
ENGEDÉLYEZVE. Ez a kialakítás lehetővé teszi, hogy az adatbázisból csak azokat a rekordokat válasszuk ki, amelyek az aktuális felhasználó számára elérhetőek. Ha ezt a kulcsszót használja, a felhasználó hibaüzenetet kap, ha olyan rekordokat próbál lekérdezni, amelyekhez nincs hozzáférése.

Ezek a kulcsszavak együtt vagy külön-külön is használhatók.

VÁLTOZÁSRA

Ez a záradék az ütközések elkerülése érdekében zárolja az adatokat. A zárolt adatok nem kerülnek kiolvasásra másik kapcsolatról a tranzakció végéig. Ebben a záradékban megadhat bizonyos táblákat, amelyeket zárolni szeretne. Ellenkező esetben minden blokkolva lesz. A kialakítás csak az automatikus blokkoló módra vonatkozik.

Leggyakrabban a "FOR CHANGE" záradékot használják egyenlegek fogadásakor. Valójában, ha egyszerre több felhasználó dolgozik a programban, miközben az egyik megkapja az egyenlegeket, a másik módosíthatja azokat. Ebben az esetben a kapott egyenleg már nem lesz helyes. Ha ezzel az ajánlattal blokkolja az adatokat, addig amíg az első alkalmazott meg nem kapja a megfelelő egyenleget és elvégzi vele az összes szükséges manipulációt, addig a második alkalmazottnak várnia kell.

VÁLASZT
Kölcsönös elszámolások. Munkavállaló,
Kölcsönös elszámolások Összeg Kölcsönös elszámolások Egyenleg
TÓL TŐL
Felhalmozási nyilvántartás. Kölcsönös elszámolások alkalmazottakkal. Egyenlegek AS Kölcsönös elszámolások
VÁLTOZÁSRA

AHOL

A konstrukció szükséges ahhoz, hogy a ki nem töltött adatokon bármilyen szelekciót szabjunk. A regiszterekből történő adatgyűjtés egyes esetekben indokoltabb kiválasztási feltételeket előírni a virtuális táblák paramétereiben. A "WHERE" használatakor először az összes rekordot megkapja, és csak ezután kerül alkalmazásra a kijelölés, ami jelentősen lelassítja a lekérdezést.

A következő egy példa egy adott pozícióval rendelkező kapcsolattartók megszerzésére irányuló kérelemre. A kiválasztási paraméter formátuma a következő: &ParameterName (a paraméter neve tetszőleges).

KIVÁLASZTÁS (CASE)

A konstrukció lehetővé teszi a feltételek közvetlen megadását a kérés törzsében.

Az alábbi példában a "További mező" szöveget fog tartalmazni attól függően, hogy a dokumentum fel van-e küldve vagy sem:

VÁLASZT
BelépőT&U.Link,
VÁLASZTÁS
AMIKOR
MAJD "A dokumentum feladva!"
ELSE "A dokumentum nincs feladva..."
VÉGE MINT Kiegészítő mező
TÓL TŐL
Dokumentum.Áru átvételeServices AS nyugtaT&C

CSATLAKOZIK

Összekapcsol két táblát egy bizonyos hivatkozási feltétel alapján.

BAL/JOBB CSATLAKOZÁS

A LEFT join lényege, hogy az első megadott táblát teljesen átveszi, a másodikat pedig a kapcsolat feltétele csatolja hozzá. Ha a másodikban nincsenek az első táblának megfelelő rekordok, akkor ezek értéke NULL lesz. Egyszerűen fogalmazva, a fő tábla az első megadott tábla, és a második tábla adatai (ha vannak ilyenek) már ki vannak cserélve annak adataira.

Például az árucikkeket az „Áruk és szolgáltatások átvétele” dokumentumokból, az árakat pedig a „Cikkárak” információs nyilvántartásból kell beszereznie. Ebben az esetben, ha valamelyik pozíció ára nem található, cserélje ki helyette a NULL értéket. A dokumentum összes eleme ki lesz választva, függetlenül attól, hogy van-e ára vagy sem.

VÁLASZT
T&U. Nómenklatúra átvétele,
Árak. Ár
TÓL TŐL
Dokumentum.Áru átvételeSzolgáltatások.Goods AS nyugtaT&C
BELSŐ ÖSSZEKAPCSOLÁS
ON KÉRDEZÉS-VÁLASZOK átvétele.Nómenklatúra = Prices.Nomenclature

A RIGHT-ban minden pontosan az ellenkezője.

TELJES KAPCSOLAT

Ez a csatlakozástípus abban különbözik a korábbiaktól, hogy ennek eredményeként mind az első, mind a második tábla összes rekordja visszakerül. Ha a megadott hivatkozási feltételhez nem található rekord az első vagy a második táblában, akkor a rendszer NULL értéket ad vissza.

Az előző példában a teljes összekapcsolás használatakor az Áru- és szolgáltatásátvételi bizonylat összes tétele, valamint a Cikkárak nyilvántartásból az összes legfrissebb ár ki lesz választva. A nem található rekordok értéke mind az első, mind a második táblázatban NULL lesz.

BELSŐ ÖSSZEKAPCSOLÁS

A BELSŐ csatlakozás és a TELJES csatlakozás közötti különbség az, hogy ha egy rekord nem található legalább az egyik táblában, akkor a lekérdezés egyáltalán nem jeleníti meg. Ennek eredményeként az Áru- és szolgáltatásátvétel bizonylatból csak azok a tételek kerülnek kiválasztásra, amelyekre a Cikkárak információs nyilvántartásban vannak bejegyzések, ha az előző példában a TELJES szót BELSŐ-re cseréljük.

CSOPORTOSÍT

Az 1C lekérdezések csoportosítása lehetővé teszi a táblázat sorainak összecsukását (mezők csoportosítását) egy bizonyos közös jellemző szerint (mezők csoportosítása). A csoportosító mezők csak összesítő függvényekkel jeleníthetők meg.

A következő lekérdezés eredménye a cikktípusok listája lesz a maximális áraikkal.

VÁLASZT
,
MAX(Ár.Ár) AS Ár
TÓL TŐL

CSOPORTOSÍT
Árak.Nómenklatúra.TípusNómenklatúra

EREDMÉNYEK

A csoportosítással ellentétben az összegek használatakor az összes rekord megjelenik, és az összesített sorok már hozzá vannak adva. A csoportosítás csak az általánosított rekordokat jeleníti meg.

Az eredmények összegezhetők a teljes táblázatra (az "Általános" kulcsszó használatával), több mezőre, hierarchikus felépítésű mezőkre ("HIERARCHIA", "CSAK HIERARCHIA" kulcsszavak). Összegzéskor nem szükséges aggregált függvényeket használni.

Vegyünk egy, a fenti példához hasonló példát csoportosítással. Ebben az esetben a lekérdezés eredménye nem csak csoportosított mezőket ad vissza, hanem részletes rekordokat is.

VÁLASZT
Prices.Nomenclature.Type of Nomenclature AS A nómenklatúra típusa,
Árak.Ár AS ár
TÓL TŐL
RegisterInformation.PricesNomenclature.SliceLast AS Árak
EREDMÉNYEK
MAXIMUM (ár)
ÁLTAL
Típusnómenklatúra

HAVING

Ez az operátor hasonló a WHERE operátorhoz, de csak összesített függvényekhez használatos. Az operátor által használtaktól eltérő mezőket csoportosítani kell. A "WHERE" operátor nem alkalmazható összesített függvényeknél.

Az alábbi példában a maximális cikkárak vannak kiválasztva, ha azok meghaladják az 1000-et, cikktípus szerint csoportosítva.

VÁLASZT

MAX(Ár.Ár) AS Ár
TÓL TŐL
RegisterInformation.PricesNomenclature.SliceLast AS Árak
CSOPORTOSÍT
Árak.Nómenklatúra.TípusNómenklatúra
HAVING
MAX(Árak.Ár) > 1000

RENDEZÉS

Az "ORDER BY" operátor rendezi a lekérdezés eredményét. Annak biztosítására, hogy a rekordok következetes sorrendben jelenjenek meg, az AUTO-ORDER használatos. A primitív típusokat a szokásos szabályok szerint rendezzük. A referenciatípusok GUID szerint vannak rendezve.

Példa az alkalmazottak név szerint rendezett listájára:

VÁLASZT
Alkalmazottak.Name AS Név
TÓL TŐL
Alkalmazottak AS alkalmazottak
RENDEZÉS
Név
AUTOMATIKUS RENDELÉS

Az 1C lekérdező nyelv egyéb konstrukciói

EGYESÜL- két lekérdezés eredménye egyben.
EGYESÍTSÜK MINDENT– hasonló a JOIN-hoz, de az azonos sorok csoportosítása nélkül.
ÜRES ASZTAL- néha használják a lekérdezések összekapcsolásakor egy üres beágyazott tábla megadására.
PUT- ideiglenes táblát hoz létre az összetett 1C lekérdezések optimalizálásához. Az ilyen kéréseket kötegelt kéréseknek nevezzük.

Lekérdezési nyelv jellemzői

SUBSTRING levágja a karakterláncot egy megadott helyről a megadott számú karakterrel.
ÉV… MÁSODIK lehetővé teszi a numerikus típus kiválasztott értékének lekérését. A beviteli paraméter egy dátum.
IDŐSZAK KEZDETE ÉS IDŐSZAK VÉGE dátumokkal való munka során használatosak. Az időszak típusa (NAP, HÓNAP, ÉV stb.) kiegészítő paraméterként van megadva.
HOZZÁADÁS lehetővé teszi, hogy hozzáadja vagy kivonja a dátumból egy bizonyos típusú (MÁSODPERC, PERC, NAP stb.) meghatározott időt.
DÁTUM KÜLÖNBSÉG meghatározza két dátum közötti különbséget, megadva a kimeneti érték típusát (NAP, ÉV, HÓNAP stb.).
NULLA lecseréli a hiányzó értéket a megadott kifejezésre.
BEMUTATÁS és PRESENTATIONLINKS lekérni a megadott mező karakterlánc-reprezentációját. Bármilyen értékhez és csak referenciaértékhez használják őket.
TÍPUS, ÉRTÉK TÍPUS a bemeneti paraméter típusának meghatározására szolgálnak.
LINK egy logikai összehasonlító operátor az attribútum érték típusához.
EXPRESSZ az érték kívánt típusra konvertálására szolgál.
DÁTUM IDŐ„Dátum” típusú értéket kap numerikus értékekből (év, hónap, nap, óra, perc, másodperc).
JELENTÉS egy 1C kérésben előre meghatározott értékek megadására szolgál - könyvtárak, felsorolások, a jellemzők típusaihoz tartozó tervek. Használati példa: " Ahol Jogi egyén = Érték(Felsorolás.Jogi egyén.Egyén)«.

Lekérdezéskészítő

Az 1C segítségével lekérdezések létrehozásához van egy nagyon kényelmes beépített mechanizmus - a lekérdezéstervező. A következő fő lapokat tartalmazza:

"Táblázatok és mezők" - tartalmazza a kiválasztandó mezőket és azok forrásait.
"Linkek" – a CONNECTION konstrukció feltételeit írja le.
"Csoportosítás" - tartalmazza a csoportosítások felépítésének leírását és az általuk összefoglalt mezőket.
"Feltételek" - felelős a kérelemben szereplő adatok kiválasztásáért.
"Speciális" - további lekérdezési paraméterek, például a "SELECT" parancs kulcsszavai stb.
„Joins / Aliases” - a táblák összekapcsolásának lehetőségeit jelzik, és beállítják az álneveket (a „HOGYAN” konstrukció).
"Rendelés" - felelős a lekérdezések eredményének rendezéséért.
"Összesen" - hasonló a "Csoportosítás" laphoz, de a "TOTALS" konstrukcióhoz használják.

Maga a kérelem szövege a bal alsó sarokban található „Kérés” gombra kattintva tekinthető meg. Ebben a formában manuálisan javítható vagy másolható.

Query Console

Egy lekérdezés eredményének gyors megtekintéséhez "Vállalati" módban, vagy összetett lekérdezések hibakereséséhez használja a . Ebbe írjuk a lekérdező szöveget, beállítjuk a paramétereket, és az eredményt is megjelenítjük.

A lekérdezési konzolt letöltheti az ITS lemezről, vagy innen.

Úgy döntöttem, hogy hozzájárulok és leírom a nyelv azon jellemzőit, amelyeket a fenti cikkek nem vettek figyelembe. A cikk kezdő fejlesztőknek szól.

1. Építés "TÓL".

Ahhoz, hogy adatokat kapjunk az adatbázisból, nem szükséges a "FROM" konstrukció használata.
Példa: A bankkönyvtárból ki kell választanunk a bankokkal kapcsolatos összes információt.
Kérés:

VÁLASZTÁSA Címtár.Bankok.*

Kijelöli az összes mezőt a Banks könyvtárból. És hasonló a lekérdezéshez:

SELECT Banks.* FROM Directory Banks AS Banks

2. Rendelje meg az adatokat referenciamező szerint

Amikor a lekérdezési adatokat primitív típusok szerint kell rendeznünk: "String", "Szám", "Dátum" stb., akkor mindent az "ORDER BY" konstrukcióval oldunk meg, ha referenciamező szerint kell adatokat rendezni? A hivatkozási mező egy hivatkozás, egy egyedi azonosító, azaz. Nagyjából elmondható, hogy egy bizonyos tetszőleges karakterkészlet és a szokásos sorrend nem hozza meg a várt eredményt. A referenciamezők megrendeléséhez az "AUTOORDER" konstrukciót használjuk. Ehhez először közvetlenül a referenciatípus szerint kell az adatokat az "ORDER BY" konstrukcióval, majd az "AUTOORDER" konstrukcióval rendezni.

Ebben az esetben a dokumentumoknál a rendelés a "Dátum-> Szám" sorrendben történik, a címtáraknál - a "Fő nézet" szerint. Ha a rendezés nem referenciamezőkön alapul, akkor az "AUTOORDER" konstrukció használata nem javasolt.

Egyes esetekben az "AUTOORDER" konstrukció lelassíthatja a mintavételi folyamatot. Hasonlóképpen átírhatja a dokumentumok automatikus elrendezése nélkül:

3. A referenciatípus szöveges ábrázolásának beszerzése. "BEMUTATÁS" konstrukció.

Ha meg kell jelenítenie egy hivatkozási típusú mezőt a megjelenítéshez, például a "Bank" mezőt, amely a "Bankok" könyvtár elemére mutató hivatkozás, akkor meg kell értenie, hogy amikor ez a mező megjelenik, egy részlekérdezés a A "Bankok" könyvtár automatikusan végrehajtásra kerül a címtárnézet eléréséhez. Ez lelassítja az adatkimenetet. Ennek elkerülése érdekében a kérésben a "REPRESENTATION" konstrukciót kell használni, hogy azonnal megkapjuk az objektum reprezentációját és máris megjelenítsük megtekintésre.

Az adatösszeállítási rendszerben alapértelmezés szerint ez a mechanizmus használatos, de a cellákban történő elrendezések generálásakor meg kell adni a referenciamező ábrázolását, és például magát a hivatkozást kell az átiratba tenni.

4. Az adatmintavétel feltétele a sablon szerint.

Például be kell szereznie az alkalmazottak mobiltelefonját a (8 -123-456-78-912) űrlapon. Ehhez a következő feltételt kell megadnia a kérelemben:

SELECT Employee.Name, Employee.Phone AS Phone FROM Directory.Employees AS Employees WHERE Phone LIKE "_-___-___-__-__"

A "_" karakter szolgáltatás, és bármely karaktert helyettesít.

5. Összegek és csoportosítások egyidejű használata.

Az összegeket gyakran a csoportosításokkal együtt használják, ilyenkor az összesített függvények elhagyhatók.

KIVÁLASZTÁSA Services.Organization AS Szervezet, Szolgáltatások.Nómenklatúra AS Nomenklatúra, ÖSSZEG(Szolgáltatások.Dokumentum összege) AS Dokumentum összege FROM Dokumentum.Szolgáltatások AS Szolgáltatások CSOPORTJAI Szolgáltatások szerint.Szervezet, Szolgáltatások.Nómenklatúra SHIE, Szervezet, Nómenklatúra

Ebben az esetben a kérés majdnem ugyanazt adja vissza, mint ez:

VÁLASZTÁSA Szolgáltatások Szervezet AS Szervezet, Szolgáltatások Nómenklatúra AS Nómenklatúra, Szolgáltatások Dokumentum összege AS Bizonylat összege A dokumentumból.

Csak az első lekérdezés fogja össze az azonos nómenklatúrával rendelkező rekordokat.

6. Mezők hivatkozásának megszüntetése.

A mezőkre ponton keresztül történő hivatkozást referenciamező-hivatkozás megszüntetési műveletnek nevezzük. Például Fizetés.Szervezet.Adminisztratív egység. Ebben az esetben a „Befizetés” bizonylat „Szervezet” hivatkozási mezőjében egy másik „Szervezetek” táblára hivatkozik, amelybe az „Adminisztrációs egység” attribútum értéke érkezik. Fontos megérteni, hogy amikor egy ponton keresztül éri el a mezőket, a platform implicit módon létrehoz egy segédlekérdezést, és csatlakozik ezekhez a táblákhoz.

Kérés:

Képviselhető:

SELECT Payment.Link, Payment.Organization, Payment.Organization, Organizations. AdministrativeUnit FROM Document.Payment AS Payment LEFT CSATLAKOZÁS Directory.Organizations AS Szervezetek Szoftver Payment.Organization = Organizations.Link

Az összetett típusú referenciamezők hivatkozásának megszüntetésekor a keretrendszer megpróbál implicit összekapcsolásokat létrehozni a mezőtípus részét képező összes táblához. Ebben az esetben a lekérdezés nem lesz optimális, ha egyértelműen ismert, hogy milyen típusú mezőről van szó, akkor a konstrukcióval típusonként kell korlátozni az ilyen mezőket. EXPRESSZ().

Például létezik egy felhalmozási nyilvántartás "Nem allokált kifizetések", ahol több dokumentum is iktatóként működhet. Ebben az esetben helytelen a regisztrátor adatainak értékeit így lekérni:

KIVÁLASZTÁS: Fel nem osztott kifizetések.Regisztrátor.Dátum, ..... FROM Felhalmozási nyilvántartás. Nem allokált kifizetések AS Unallokált kifizetések

korlátoznia kell az összetett mezőnaplózó típusát:

SELECT EXPRESS (Nem allokált kifizetések. Nyilvántartó mint dokumentum. Befizetés). Dátum, ..... A felhalmozási nyilvántartásból. Fel nem osztott kifizetések, mint fel nem osztott kifizetések

7. Építés "HOL"

Két tábla bal oldali összekapcsolása esetén, amikor a "WHERE" feltételt a jobb oldali táblára állítja, hasonló eredményt kapunk, mint a táblák belső összekapcsolása esetén.

Példa. Az Ügyfélkönyvtárból ki kell választani az összes Ügyfelet, és azoknak az ügyfeleknek, akiknek van "Szervezet" = &Szervezet attribútum értékű fizetési bizonylata, jelenítse meg a "Befizetés" bizonylatot, akinek nincs, ne jelenítse meg.

A lekérdezés eredménye csak azon ügyfelek rekordjait adja vissza, akiknél a paraméterben szerepelt a szervezet szerinti fizetés, és kiszűri a többi vásárlót. Ezért először egy ideiglenes táblában kell megkapnia az "ilyen és ilyen" szervezetre vonatkozó összes kifizetést, majd bal oldali csatlakozással csatlakoznia kell az "Ügyfelek" könyvtárhoz.

SELECT Payment.Reference AS Fizetés, Fizetés.Részvényes AS Ügyfél PUT tofizetések FROM Dokumentum.Fizetés AS Fizetés WHERE Fizetés.Osztály = &Osztály; ////////////////////////////////////////////////// //////////////////////////////////////// Select Clients.Reference As Client, Isnull (Topayments.Payment, ") Fizetés a könyvtárból .Clients AS Clients LEFT CSATLAKOZÁS

Ezt az állapotot más módon is megkerülheti. közvetlenül a két tábla kapcsolatában szükséges a "HOL" feltételt előírni. Példa:

SELECT Clients.Reference, Payment.Reference FROM Directory.US_Subscribers AS ST_Subscribers LEFT JOIN Document.Payment AS Payment SOFTWARE (Clients.Reference = Payment.Client AND Payment.Client.Name LIKE "Cukorzsák") GROUP BY Clients, Payment.Reference. Link

8. Csatlakozás beágyazott és virtuális táblákhoz

Allekérdezések gyakran szükséges az adatok valamilyen feltétel szerinti kiválasztásához. Ha ezután más táblákkal együtt használja őket, akkor ez kritikusan lelassíthatja a lekérdezés végrehajtását.

Például egyes ügyfelek esetében meg kell kapnunk az egyenleg összegét az aktuális dátumra.

SELECT UnallocatedPayBalances.Customer, UnallocatedPaymentsRemains.AmountBalance FROM (SELECT Clients.Reference AS Reference FROM Directory.Clients AS Clients WHERE Clients.Ref B(&Clients)) AS NestedQuery LEFT JOIN Felhalmozási Szoftver NesedReferenceSt.Unal. .Reference = UnallocatedPaymentsRemains .Ügyfél

Egy ilyen lekérdezés végrehajtásakor a DBMS-optimalizáló valószínűleg hibákat követ el a terv kiválasztásakor, ami szuboptimális lekérdezéshez vezet. Két tábla összekapcsolásakor a DBMS-optimalizáló a két táblában lévő rekordok száma alapján kiválaszt egy algoritmust a táblák összekapcsolásához. Beágyazott lekérdezés esetén rendkívül nehéz meghatározni, hogy a beágyazott lekérdezés hány rekordot fog visszaadni. Ezért a beágyazott lekérdezések helyett mindig ideiglenes táblákat kell használni. Tehát írjuk át a lekérdezést.

SELECT Clients.Link AS Link PUT Clients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&kliensek) ; ////////////////////////////////////////////////// ///////////////. .Referencia FROM tClients)) AS UnallocatedPaymentsBalances ON tClients.Reference = UnallocatedPaymentsBalances.Clients

Ebben az esetben az optimalizáló képes lesz meghatározni, hogy a tClients ideiglenes tábla hány rekordot használ, és kiválaszthatja az optimális táblaillesztési algoritmust.

Virtuális asztalok , lehetővé teszi, hogy a legtöbb alkalmazási feladathoz szinte kész adatokhoz jusson.(Slice of the First, Slice of the Last, Residuals, Turnovers, Residuals and Turnovers) A kulcsszó itt a virtuális. Ezek az asztalok nem fizikaiak, hanem menet közben szereli össze a rendszer, azaz. a virtuális táblákból származó adatok fogadásakor a rendszer a regiszterek végső tábláiból gyűjti az adatokat, összeállítja, csoportosítja és kiadja a felhasználónak.

Azok. amikor egy virtuális táblával csatlakozik, akkor egy segédlekérdezéssel csatlakozik. Ebben az esetben a DBMS-optimalizáló választhat egy nem optimális csatlakozási tervet is. Ha a lekérdezés nem jön létre elég gyorsan, és a lekérdezés virtuális táblákban összekapcsolásokat használ, akkor javasolt a virtuális táblákhoz való hozzáférést átvinni egy ideiglenes táblába, majd két ideiglenes tábla között összekapcsolni. Írjuk át az előző lekérdezést.

SELECT Clients.Link AS Link PUT Clients FROM Directory.Clients AS Clients INDEX BY Link WHERE
Clients.Link B (&kliensek) ; ////////////////////////////////////////////////// / ///////////////////////////// KIVÁLASZTÁSA UnallocatedPayments.AmountBalance, UnalllocatedPayments.Customer AS Customer AZ egyenlegeket TEGYE A Felhalmozási Nyilvántartásból.UnalllocatedPayments. Egyenlegek(, Client IN (SELECT tClients.Reference FROM tClients)) AS UnallocatedPaymentsBalances; ////////////////////////////////////////////////// ////////////////////////////// SELECT tClients.Reference, thenRemains.SumRemainder AS SumRemainder FROM tClients AS tClients tClients.Reference = tRemainder .Ügyfél

9.A lekérdezés eredményének ellenőrzése.

A lekérdezés végrehajtásának eredménye üres lehet; az üres értékek ellenőrzéséhez használja a következő konstrukciót:

RequestRes = Request.Execute(); Ha reQuery.Empty() then Return; EndIf;

Módszer Üres() módszerek előtt kell használni Választ() vagy Unload(), mivel időbe telik a gyűjtemény megszerzése.

Nem felfedezés senki számára, hogy nagyon nem kívánatos a lekérdezések ciklusban történő használata. Ez kritikusan befolyásolhatja egy adott funkció működési idejét. Nagyon kívánatos, hogy a kérésben szereplő összes adatot megkapja, és csak ezután dolgozza fel az adatokat hurokban. De néha vannak olyan esetek, amikor lehetetlenné válik a kérés kivonása a hurokból. Ebben az esetben az optimalizálás érdekében a lekérdezés létrehozását áthelyezheti a cikluson kívülre, és a ciklusban helyettesítheti a szükséges paramétereket, és végrehajthatja a lekérdezést.

Ez megmenti a rendszert a kérés ciklusban történő elemzésétől.

11. Építés "HAVING".

A lekérdezésekben meglehetősen ritka konstrukció. Lehetővé teszi, hogy feltételeket szabjon az összesített függvények értékeire (SZUM, MINIMUM, ÁTLAG stb.). Például csak azokat az ügyfeleket kell kiválasztania, akiknek a fizetési összege szeptemberben meghaladta a 13 000 rubelt. Ha a "WHERE" feltételt használja, először létre kell hoznia egy ideiglenes táblát vagy egy beágyazott lekérdezést, csoportosítania kell a rekordokat a fizetés összege szerint, majd feltételt kell szabnia. A "HAVING" konstrukció segít ennek elkerülésében.

KIVÁLASZTÁS Fizetés.Ügyfél, SUM(Fizetés.Összeg) MINT összeg A dokumentumból.Fizetés AS Fizetés WHERE HÓNAP(Fizetés.Dátum) = 9 CSOPORT Fizetés szerint.Ügyfél, HA VONATKOZIK ÖSSZEG(Fizetés.Összeg) > 13000

A konstruktorban mindössze annyit kell tennie, hogy lépjen a „Feltételek” fülre, adjon hozzá egy új feltételt, és jelölje be az „Egyéni” jelölőnégyzetet. Akkor csak írj Összeg(Fizetés.Összeg) > 13000

12. Null érték

Itt nem írom le az adatbázisban szereplő háromértékű logika alapelveit, sok cikk van ebben a témában. Csak egy pillantás, hogyan NULLA befolyásolhatja a lekérdezés eredményét. A NULL érték valójában nem érték, és az a tény, hogy az érték nincs definiálva, ismeretlen. Ezért a NULL-on végzett bármely művelet NULL-t ad vissza, legyen az összeadás, kivonás, osztás vagy összehasonlítás. A NULL értéket nem lehet összehasonlítani a NULL értékkel, mert nem tudjuk, mivel hasonlítsuk össze. Azok. mindkét összehasonlítás: NULL = NULL, NULL<>A NULL nem igaz vagy hamis, ez ismeretlen.

Nézzünk egy példát.

Azon ügyfeleknél, akiknek nincs fizetésük, meg kell jelenítenünk az „Attribútum” mezőt „Nincs befizetés” értékkel. És biztosan tudjuk, hogy vannak ilyen ügyfeleink. És hogy tükrözze a fent leírtak lényegét, tegyük ezt így.

KIVÁLASZTÁSA "Nincs kifizetés" AS Attribútum, NULL AS Dokumentum PUT a kifizetésekhez; ////////////////////////////////////////////////// /////////////////////////////// SELECT Clients.Link AS Client, Payment.Link AS Payment PUT tClientPayment FROM Directory.Clients AS Clients LEFT JOIN Document.Payment AS Payment Software Clients.Link = Fizetés.Részvényes; ////////////////////////////////////////////////// /////////////////////////////// tClientPayment.Customer FROM FROM tClientPay AS tClientPayment INTERNAL JOIN topayments AS topayments BY tClientPayment.Payment = dokumentumokat

Ügyeljen a második ideiglenes táblára tCustomerPayment. A bal oldali csatlakozással kiválasztom az összes ügyfelet és az összes fizetést ezekhez az ügyfelekhez. Azon ügyfelek esetében, akiknek nincs fizetésük, a „Fizetés” mező NULL lesz. A logikát követve az első ideiglenes táblában a "kifizetések" 2 mezőt jelöltem ki, ezek közül az egyik NULL, a második a "Nincs befizetés" sor. A harmadik táblázatban a "tClientPayment" és a "tPayment" táblákat a "Fizetés" és a "Dokumentum" mezőkkel egy belső összekapcsolással csatlakozom. Tudjuk, hogy az első táblában a "Dokumentum" mező NULL, a másodikban pedig azok is NULL, akiknek nincs befizetése a "Fizetés" mezőben. Mi adja vissza nekünk ezt a kapcsolatot? És nem ad vissza semmit. Mivel a NULL = NULL összehasonlítás nem igazodik ki.

Annak érdekében, hogy a lekérdezés a várt eredményt adja vissza, átírjuk:

KIVÁLASZTÁSA "Nincs kifizetés" AS Sign, ÉRTÉK (Dokumentum. Fizetés. Üres hivatkozás) AS Dokumentum PUT to Payments; ////////////////////////////////////////////////// /////////////////////////////// SELECT Clients.Reference AS Client, ISNULL(Fizetés.Referencia, ÉRTÉK(Dokumentum.Fizetés. EmptyReference )) A tClientPayment TELEPÍTÉSE FROM Directory.Clients AS Clients LEFT JOIN Document.Payment AS Payment ON Clients.Reference = Payment.Shareholder; ////////////////////////////////////////////////// //////////////////////////. Dokumentum

Most, a második ideiglenes táblázatban jeleztük, hogy ha a "Fizetés" mező NULL, akkor ez a mező = üres hivatkozás a fizetési bizonylatra. Az első táblázatban a NULL-t is null hivatkozásra cseréltük. Most nem NULL mezők vesznek részt a kapcsolatban, és a lekérdezés a várt eredményt adja vissza.

A cikkben szereplő összes kérés olyan helyzeteket tükröz, amelyeket meg szeretnék fontolni, és semmi több. RÓL RŐL nem is lehetnek őrültek vagy nem optimálisak, a lényeg, hogy a példa lényegét tükrözze.

13. Nem dokumentált tervezési jellemző "VÁLASZTÁS MIKOR...AKKOR....VÉG".

Abban az esetben, ha a kérésben le kell írni a "Feltételek" konstrukciót, akkor a szabványos szintaxist használjuk:

SELECT CHOICE WHEN Users.Name = "Vasya Pupkin" THEN "Kedvenc alkalmazottunk" EGYÉB "Ezt nem tudjuk" END AS Mező1 FROM Címtárból.Users AS Users

De mi van akkor, ha például a hónap nevét kell megkapnunk a lekérdezésben? Hatalmas konstrukciót írni egy lekérdezésben csúnya és időigényes, ezért a fenti jelölési forma segíthet nekünk:

Választható hónap (a_grafikonon alapuló értékelés elszámolása. Periodrass számla), amikor 1, majd „január”, amikor 2, majd „február”, amikor 3, majd „március”, amikor 4 akkor „április” 5 majd „május”, amikor 6, majd „június”, amikor 7 „július”, majd „július” 8. MAJD „augusztus” WHEN 9. MAJD „szeptember” WHEN 10. MAJD „október” MIKOR 11. MAJD „november”, MIKOR 12. MAJD „December” HÓNAPNAK VÉGE

Most a kialakítás nem tűnik olyan nehézkesnek, és könnyen észlelhető.

14. Kötegelt lekérdezés végrehajtása.

Annak érdekében, hogy ne hozzon létre kéréseket, létrehozhat egy nagy kérést, csomagokra bonthatja, és már dolgozhat vele.
Például be kell szereznem a "Felhasználók" könyvtárból a "Születési dátum" mezőket és az egyes felhasználók számára elérhető szerepköröket. hogy az űrlapon különböző táblázatos részekre rakja ki. Természetesen ezt megteheti egy lekérdezéssel, majd ismételgetni kell a rekordokat vagy össze kell csuknia, vagy megteheti ezt:

SELECT Users.Link AS Name, Users.Date of Birth, Users.Role ENTER Users FROM Directory.Users AS Users; ////////////////////////////////////////////////// /////////////////////////////// SELECT tuUsers.Name, tuUsers.Date of Születési dátum FROM tuUsers AS tuUsers GROUP BY tuUsers.Name , tuSers Születési dátum; ////////////////////////////////////////////////// /////////////////////////////// SELECT wUsers.Name, wUsers.Role FROM wUsers AS wUsers GROUP BY wUsers.Name, wUsers Születési dátum

tPackage = Request.ExecutePackage();

TP_BirthDate = tCsomag.Unload();
TP_Roles = tPackage.Unload();

Amint látjuk, a lekérdezés kötegben is végrehajtható, és az eredménnyel tömbként dolgozhat. Egyes esetekben nagyon kényelmes.

15. A kötegelt kérés feltételei

Például van egy kötegelt kérésünk, ahol először a "Név, születési dátum, kód" mezőket kapjuk meg a "Felhasználók" könyvtárból, és a "Magánszemélyek" könyvtárból szeretnénk lekérni az ezekre a mezőkre vonatkozó feltételekkel rendelkező rekordokat.

SELECT Users.Individual.Name AS Név, Users.Individual.Date of Birth AS Születési dátum, Users.Individual.Code AS Code PUT in Users FROM Directory.Users AS Users; ////////////////////////////////////////////////// ///////////////////////////////////////////////////.

Ilyen feltételeket alkalmazhat:

WHERE Individuals.Code At (SELECT TueUsers.Code FROM TuUsers) AND Individuals.Name At (SELECT TueUsers.Code FROM TuUsers) AND Individuals.Date of Birth At (SELECT TueUsers.Date of Birth FROM TuUsers)

És ez így lehetséges:

WHERE (Individuals.Code, Individuals.Name, Individuals.Date of Birth) AT (SELECT TueUsers.Code, TueUsers.Name, TueUsers.Date of Birth FROM TueUsers)

És feltétlenül tartsa be a szabályokat.

16. Hívja a Query Builder alkalmazást a „Condition” (állapot) értékhez a Batch Queryben

Amikor feltételt kell előírnia, mint a fenti példában, elfelejtheti, hogyan hívják ezt vagy azt a mezőt a virtuális táblában.
Például feltételt kell szabnia a "Születési dátum" mezőben, és a virtuális táblázatban ez a mező neve "Az adós születési dátuma", és ha elfelejtette a nevet, akkor ki kell lépnie a szerkesztésből. feltételt mentés nélkül, és nézze meg a mező nevét. Ennek elkerülésére használhatja a következő trükköt.

A "B" konstrukció után zárójeleket kell tenni, és a zárójelek között üres helyet (szóközt) kell hagyni, kiválasztani ezt a helyet és meghívni a lekérdezés konstruktorát. A konstruktor hozzáférhet az összes kötegelt lekérdezési táblához. A vétel mind a virtuális regisztertáblákon, mind a „Feltételek” fülön működik. Ez utóbbi esetben be kell jelölni az "A (tetszőleges feltétel)" jelölőnégyzetet, és be kell lépni az "F4" szerkesztési módba.

A lekérdezéseket gyakran menet közben találják ki, és csak arra szolgálnak, hogy megjelenítsék azokat a „trükköket”, amelyeken gondolkodtam.

Meg akartam fontolni az indexek használatát a lekérdezésekben, de ez egy fájdalmasan kiterjedt téma. Felteszem egy külön cikkbe, vagy később felteszem ide.

upd1. 11., 12. bekezdés
upd2. 13,14,15,16 tételek

Használt könyvek:
Lekérdezési nyelv "1C:Enterprise 8" - E.Yu. Khrustalev
Szakmai fejlődés az 1C:Enterprise 8 rendszerben.

/
Adatfeldolgozás megvalósítása

Lekérdezési eredmények rendelése

1.1. Ha a lekérdezési eredmények feldolgozásának algoritmusa a lekérdezés rekordjainak sorrendjétől függ, vagy ha a lekérdezés feldolgozási eredménye ilyen vagy olyan formában jelenik meg a felhasználó számára, akkor a lekérdezés szövegében a mondatot kell használni. RENDEZÉS. Kifejezés hiányában RENDEZÉS nem lehet feltételezni, hogy a rekordok milyen sorrendben jelennek meg a lekérdezés eredményeiben.

Tipikus példák az előforduló problémákra:

eltérő sorsorrend a táblázatos részben a kitöltéskor a lekérdezés eredményének megfelelően;
eltérő adatkiadási sorrend (sorok, oszlopok) a jelentésekben;
bizonylatmozgások különböző kitöltése a lekérdezés eredménye alapján (*).

Növekszik annak a valószínűsége, hogy ugyanazon műveletek végrehajtása során eltérő eredmények születnek

amikor egy információs bázist egy másik DBMS-re migrál
a DBMS verzió megváltoztatásakor
a DBMS paraméterek megváltoztatásakor

* Megjegyzés: a mozgásokat képező lekérdezések eredményeinek rendelése csak akkor indokolt, ha a rendelés a mozgásokat generáló algoritmus részét képezi (például a FIFO szerinti áruszállítmányok egyenlegének leírása). Más esetekben a rekordokat nem szabad megrendelni, mivel a további rendezés túlzott terhelést jelent a DBMS-en.

1.2. Ha a lekérdezés eredményét ilyen vagy olyan módon meg kell jeleníteni a felhasználó számára, akkor

az ilyen lekérdezések eredményeit primitív típusok mezői szerint kell rendezni;
A referenciatípusok mezői szerinti rendezést e mezők karakterlánc-reprezentációinak sorrendjével kell helyettesíteni.

Ellenkező esetben a sorok sorrendje véletlenszerűnek (megmagyarázhatatlannak) tűnik a felhasználó számára.

Lásd még: Értéktáblázatok sorainak rendezése

1.3. Nincs ajánlat RENDEZÉS csak akkor indokolt

a lekérdezések eredményeit feldolgozó algoritmus nem támaszkodik a rekordok meghatározott sorrendjére
a kitöltött kérés feldolgozásának eredménye nem jelenik meg a felhasználó számára
lekérdezés eredménye – nyilván egy rekord

Megosztás a tervezéssel KÜLÖNBÖZŐ

2. Ha a lekérdezés a konstrukciót használja KÜLÖNFÉLE, a rendelést csak a kiválasztásban szereplő mezőkkel szabad végrehajtani (a rovatban VÁLASZT).

Ez a követelmény a lekérdezés végrehajtásának következő jellemzőjéhez kapcsolódik: a rendezési mezők implicit módon szerepelnek a kiválasztási mezőkben, ami viszont a lekérdezés eredményeként több sor megjelenéséhez vezethet, amelyekben a kiválasztási mezők azonos értékei vannak.

Az AUTOORDER konstrukció használatára vonatkozó korlátozások

3. Építés használata ELSŐ a tervezéssel együtt AUTOMATIKUS RENDELÉS tiltott.

Más esetekben a tervezés AUTOMATIKUS RENDELÉS szintén nem ajánlott használni, mivel a fejlesztő nem szabályozza, hogy mely mezőket használja a rendelés. Egy ilyen konstrukció alkalmazása csak olyan esetekben indokolt, amikor a rekordok eredő sorrendje nem fontos, de annak a használt DBMS-től függetlenül azonosnak kell lennie.

Figyelem! Íme a lecke próbaverziója, melynek anyagai nem biztos, hogy teljesek.

Jelentkezzen be diákként

Jelentkezzen be tanulóként az iskolai tartalmak eléréséhez

1C 8.3 lekérdező nyelv kezdő programozóknak: rendelés

Írjunk lekérdezést, amely egy táblázatból származik Címtár.Ételélelmiszer kódja és neve:

SELECT Code, Name FROM Directory. Étel

Mint mindig, futtassa ezt a lekérdezést a számítógépén.

Nagy valószínűséggel a következő eredményt kapja:

Lehet, hogy meg fog lepődni, de a lekérdezésnek ezzel a megírásával senki sem garantálja, hogy pontosan ezt a sorrendet adjuk ki a táblázatban. Különböző DBMS-eken a kliens-szerver üzemmód használata esetén az eredmény a következő lehet:

És ..., nos, általában megérted, hogy ha nem adjuk meg a lekérdezés eredményének rendezési (rendezési) sorrendjét, akkor ez a sorrend teljesen bármi lehet.

Ezért bevált gyakorlat, amikor lekérdezéseket írunk a lekérdezések eredményeinek sorrendjében, még akkor is, ha ezt kifejezetten nem követeljük meg.

RENDELÉS szakaszonként

A mezők, amelyek szerint rendezni szeretné a lekérdezést, a szakaszban vannak felsorolva RENDEZÉS vesszővel elválasztva:

A rendelési mező nevét két kulcsszó egyike követheti:

WHO - növekvő sorrendben.
DESC - csökkenő sorrendben.

Ha nem adja meg e szavak egyikét sem, akkor a rendezés növekvő sorrendben történik.

Ismerettel felvértezve rendezzük lekérdezésünk eredményét csökkenő mezőbe Kód:

Most rendezzük el a következő táblázatot

hogy először a mezők szerinti rendezés történjen Íz növekvő, majd (az azonos mezőértékű sorok között Íz) mezők szerint lett rendezve Szín csökkenő:

VÁLASSZON Íz, színt A KÖNYVTÁRBÓL. Étel RENDELÉS ÍZLÉSRE. Név VOZR, Szín. Név DESC

Külön felhívom a figyelmet arra, hogy nem a mezők szerint határoztuk meg a rendezést ÍzÉs Szín,és vonós kellékeik által Név. Ön a lecke próbaverzióját olvassa, a teljes leckék megtalálhatók.

Ez annak a ténynek köszönhető, hogy a rendezés csak olyan mezők szerint lehetséges, amelyek az alábbi típusok valamelyikével rendelkeznek: Vonal, Szám, dátum.

És a mezők ÍzÉs Szín hivatkozások a könyvtárak elemeire ÍzÉs Szín, ami alapján a rendezésnek nincs értelme (ebben az esetben a rendezést a hivatkozás belső azonosítója végzi el). De rendezheti ezen elemek egyik attribútuma szerint is. Esetünkben a legmegfelelőbb a string attribútum Név.

Automatikus rendelés lehetősége

Az AUTOORDER kulcsszó lehetővé teszi a mezők automatikus generálását a lekérdezések eredményeinek rendezéséhez.

Ezzel a lehetőséggel most részletesen megismerkedünk, de rögtön szeretnék egy fenntartást tenni, hogy az 1C cég módszertani ajánlásaiban nem javasolja feleslegesen a használatát (ennek okairól beszélünk).

Akkor gyerünk.

Először is, az AUTOORDER kulcsszó közvetlenül az ORDER BY rész után vagy helyett is elhelyezhető egy lekérdezésben:

Az automatikus elrendezés a következő elvek szerint működik:

1. eset

Ha egy kérésben:

van egy rész RENDELÉS

A keresőtábláknál az alapértelmezett rendezési mezők a kód és a név, amelyek közül a választás a konfigurátorban megadott keresési beállításoknak megfelelően történik:

A bizonylattáblázatok esetében az alapértelmezett rendezési mező a bizonylat dátuma.

Vegyünk egy példát:

A rendezési mező óta Kedvenc szín típusa van Referencia.Színek Név

2. eset

Ha egy kérésben:

de van egy EREDMÉNYEK szakasz (ezt végigmegyünk)

Ebben az esetben a lekérdezés eredménye az összes mező szerint lesz rendezve (ugyanabban a sorrendben).

3. eset

Ha egy kérésben:

hiányzik a rész ORDER BY
nincs RESULTS ON szakasz
de van egy GROUP BY rész (átmentünk a csoportosításon)

Ebben az esetben a lekérdezés eredménye mezők csoportosítása szerint lesz rendezve (ugyanabban a sorrendben).

Vegyünk egy példát:

Mivel a csoportosítási mező Város típusa van Directory.Cities, amelynek beállításaiban a mező főnézetként van kiválasztva Név, akkor ez a lekérdezés egyenértékű a következővel:

4. eset

Végül, ha a kérésben:

hiányzik a rész ORDER BY
nincs RESULTS ON szakasz
A GROUP BY szakasz hiányzik

Ebben az esetben a lekérdezés eredménye azon táblák alapértelmezett rendezési mezői szerint lesz rendezve, amelyekből az adatok ki vannak választva, abban a sorrendben, ahogyan azok a lekérdezésben megjelennek.

Vegyünk egy példát:

Miért nem kívánatos az automatikus elrendezés?

Az automatikus rendezés jó:

univerzális lekérdezések esetén, amikor a fejlesztő nem tudja előre látni, hogy mely táblákból kérik le az adatokat
azokra az esetekre, amikor a rekordok eredő sorrendje nem fontos, de azonosnak kell lennie, függetlenül a használt DBMS-től

Minden más esetben nem kívánatos az automatikus rendezés funkció használata, mivel azok a mezők, amelyek ma rendezési mezők, holnap már nem lehetnek rendezési mezők.

Például ma már írhatunk olyan kódot, amely érzékeny a keresési eredményekre Étel mezők szerint lettek rendezve Név.

És holnap az 1C (vagy egy másik fejlesztő) megváltoztatja az adatbázis-beállításokat a konfigurátorban úgy, hogy a könyvtár alapértelmezett rendezési mezője legyen Étel például mezővé válik Kód. És ha a lekérdezésben automatikus rendezést használtunk, akkor a jelentésünk megszakad, mert a rendezési sorrend már más lesz. Ön a lecke próbaverzióját olvassa, a teljes leckék megtalálhatók.

Ezért mindig próbáljon meg konkrét mezőket és egy meghatározott rendezési sorrendet megadni a szakaszban RENDEZÉS, egy ilyen kérést már nem lehet csak így megszegni:

SELECT Code, Name FROM Directory. Ételek RENDELÉSE Név KOR SZERINT

Csináld meg a tesztet

Indítsa el a tesztet

1. A lekérdezések eredményei alapértelmezés szerint sorrendben vannak

2. A lekérdezések eredményei a szerint rendezhetők

3. A „ORDER BY FIELD_NAME” rendezési elv szerint történik

4. Növekvő sorrendbe rendezéshez a ORDER BY részben meg kell adni a mező nevét és a kulcsszót

5. A csökkenő sorrendbe rendezéshez a ORDER BY részben meg kell adni a mező nevét és a kulcsszót

6. Lekérdezésekben lehetséges az automatikus rendelés