Pyetjet e mbivendosura. Pyetjet e ndërlidhura që punojnë me pyetjet e grupit

Pyetjet e mbivendosura. Pyetjet e ndërlidhura që punojnë me pyetjet e grupit

Ky artikull është menduar për lexuesit që janë të njohur me gjuhën SQL.

Gjuha e pyetjeve 1C, e përdorur që nga versioni 8, është bërë sot një mjet i dobishëm për të punuar me bazat e të dhënave, i cili ju lejon të lexoni prej tyre, por jo të shkruani. Në mënyrë sintaksore, gjuha e pyetjes është shumë e ngjashme me gjuhën SQL, por në Rusisht.

Më poshtë është një tabelë e korrespondencës midis gjuhës kryesore të pyetjes dhe operatorëve SQL:

Operatorët e gjuhës së pyetjeve 1C

Deklarata SQL

TE NDRYSHME

PËRBËRJE

GRUP NGA

KOMBINOHET

NDAJ SIPAS

Dhe kjo nuk është një listë e plotë. Informacion më i plotë i referencës mbi operatorët e disponueshëm të gjuhës së pyetjes mund të merret në projektuesin e pyetjeve, i cili do të diskutohet më poshtë.

Ekzekutimi i një kërkese 1C nga kodi i programit kryhet duke përdorur objektin e integruar të gjuhës "Kërkesë". Një shembull i shkrimit të një pyetjeje të bazës së të dhënave duke përdorur gjuhën e integruar të programimit:

Kërkesë = Kërkesë e re; Query.Text = "ZGJEDH | Sinonim.Lidhja AS Lidhje |FROM | Drejtoria.Direktoria1 AS Sinonim"; Zgjidh = Query.Run().Select(); Ndërsa Selection.Next() Loop // Fut përpunimin e përzgjedhjes SelectionDetailedRecords EndCycle;

Metoda "Run" ekzekuton pyetjen, metoda "Select" kthen një vlerë të tipit "SelectFromQueryResult". Ju gjithashtu mund të përdorni metodën Unload, e cila kthen një tabelë vlerash.

Parametrat e kërkesës ruhen në pronën "Parametrat" ​​(në këtë rast, kjo është një strukturë, kështu që të gjitha metodat e strukturës janë të zbatueshme këtu - futni, fshini, etj.).

Një shembull i vendosjes së parametrit "Query.Parameters.Insert" ("Directory", DirectoryLink). Në kërkesë, mund të përdorni parametrat duke përdorur ampersand "&Directory". Më poshtë është një shembull i një kërkese duke përdorur parametrat:

Kërkesë = Kërkesë e re; Query.Text = "ZGJIDH | Përdoruesit.Lidhja AS Lidhje, | Përdoruesit.Prindi AS prind, | Përdoruesit.Emri AS Emri |NGA | Drejtoria.Përdoruesit AS Përdorues |KU | Përdoruesit.Lidhja = &Direktoria"; Query.Parameters.Insert("Directory", DirectoryLink); Zgjidh = Query.Run().Select(); Ndërsa Selection.Next() Loop // Fut përpunimin e përzgjedhjes SelectionDetailedRecords EndCycle;

Le të kujtojmë se gjuha e pyetjes është menduar vetëm për leximin e të dhënave nga baza e të dhënave, kështu që nuk ka analoge të deklaratave të tilla SQL si INS ERT dhe UPDATE. Të dhënat mund të modifikohen vetëm përmes modelit të objektit të gjuhës së integruar të programimit 1C. Gjithashtu në gjuhën e pyetjeve 1C ka operatorë që nuk kanë analoge në SQL, për shembull:

  • NË HIERARKI
  • VENDI
  • INDEKSI NGA

NË HIERARKI– ju lejon të zgjidhni të gjithë elementët e drejtorisë hierarkike që përfshihen në hierarkinë e lidhjes së transferuar. Shembull i kërkesës duke përdorur NË HIERARKI:

SELECT Produktet.Lidhja, Produktet.Artikulli NGA Drejtoria.Produktet AS Produkte WHERE Produkte.Lidhja NË HIERARKI(&Citrus)"

Në këtë rast, rezultati do të kthejë të gjithë elementët vartës të drejtorisë së nomenklaturës Citrus, pavarësisht sa nivele hierarkie ka kjo direktori.

Gjithashtu, për shembull, detyra është të gjesh një produkt me emrin "Pen". Produkti duhet të përfshihet në hierarkinë "Stationery". Mallrat”, domethënë, ne nuk duhet të kërkojmë dorezën e derës. Struktura e nomenklaturës në këtë rast është si më poshtë:

Zyrë

|_ Stilolapsa |_ Stilolaps i kuq |_ Stilolaps blu |_ Stilolapsa me bojë |_ Vizata

Aksesorë

|_ Doreza dyersh |_ Dorezë e thjeshtë e derës |_ Dorezë luksoze

Ne shkruajmë kërkesën e mëposhtme:

ZGJIDHni Produktet.Lidhja, Produktet.Artikulli NGA Drejtoria.Produktet AS Produkte WHERE Produkte.Emri si "Pen%" DHE Produkte.Lidhja NË HIERARKI (& Stationery)"

Kur përdorni dizajnin NË HIERARKIështë e nevojshme të merret parasysh që nëse kaloni një lidhje boshe në parametrin "Office", ekzekutimi i kërkesës do të ngadalësohet, pasi platforma do të kontrollojë çdo element për të parë nëse i përket rrënjës.

VENDI– Kjo deklaratë e vendos rezultatin në një tabelë të përkohshme. Shembull i kërkesës:

SELECT Users.Link AS Link, Users.Parent AS Prind, Users.Emri AS Emri PLACE SelectedUsers FROM Directory.Users AS Users WHERE Users.Link = &Directory; SELECT SelectedUsers.Link AS Link, SelectedUsers.Parent AS Prind, SelectedUsers.Name AS Emri FROM SelectedUsers AS SelectedUsers

Ky pyetje SQL do të ekzekutohet nga disa pyetje:

  • Krijimi i një tabele të përkohshme (platforma mund të "ripërdorë" tabela të përkohshme të krijuara më parë, kështu që krijimi nuk ndodh gjithmonë);
  • Vendosja e të dhënave në një tabelë të përkohshme;
  • Ekzekutimi i pyetjes kryesore, përkatësisht SEL ECT nga kjo tabelë e përkohshme;
  • Shkatërrimi/pastrimi i një tavoline të përkohshme.

Një tabelë e përkohshme mund të shkatërrohet në mënyrë eksplicite, përmes konstruktit SHKATËRRON, ose në mënyrë implicite - kur mbyllni menaxherin e përkohshëm të tabelës.

Objekti "Query" i gjuhës së integruar të programimit ka një pronë "Temporary Table Manager", i cili është menduar për të punuar me tabela të përkohshme. Shembull i kodit:

MVT = New TemporaryTableManager(); Kërkesë = Kërkesë e re; Query.TemporaryTableManager = MVT;

Pas ekzekutimit të një pyetësori, ndryshorja MVT mund të përdoret për herë të dytë në një pyetje tjetër, që është padyshim një avantazh tjetër i përdorimit të tabelave të përkohshme. Në këtë rast, tabela e përkohshme nga baza e të dhënave do të fshihet kur thirret metoda “Close”...

MVT.Close();

...ose kur pastroni një ndryshore nga memoria, domethënë kur ekzekutoni metodën në të cilën është deklaruar ndryshorja. Tabelat e përkohshme rrisin ngarkesën në nënsistemin e diskut, kështu që nuk duhet të krijoni shumë nënsisteme të përkohshme (për shembull në një lak) ose nënsisteme me vëllim të madh.

INDEKSI NGA– ky operator përdoret në lidhje me operatorin VENDI. Kur krijon një tabelë të përkohshme, ky operator mund të indeksojë tabelën që krijohet, gjë që përshpejton ndjeshëm punën me të (por vetëm nëse indeksi përputhet me pyetjen tuaj).

Konsultim eksperti falas

Faleminderit për kërkesën tuaj!

Një specialist 1C do t'ju kontaktojë brenda 15 minutave.

Karakteristikat e disa operatorëve të gjuhës së pyetjeve

PËR NDRYSHIM– ky operator ka për qëllim të bllokojë një tabelë specifike të pyetjeve (ose të gjitha tabelat që marrin pjesë në pyetje). Kyçja realizohet duke aplikuar një bllokues U në tryezë. Në SQL kjo zbatohet nëpërmjet aludimit UPDLOCK. Ky dizajn është i nevojshëm për të parandaluar bllokimet. Shembull i një kërkese me një ndërtim PËR NDRYSHIM:

SELECT Users.Link AS Link, Users.Parent AS Prind, Users.Name AS AS Emri FROM Directory.Users AS Users LIFT JOIN Directory.RFK AS RFK BY Users.RFK = RFK.Link për të NDRYSHUAR Drejtorinë.Përdoruesit

Në këtë shembull, U lock do të vendoset në tabelën e Përdoruesve. Nëse nuk specifikoni një tabelë për një bllokim, ajo do të vendoset në të gjitha tabelat që marrin pjesë në pyetje. Është e rëndësishme të theksohet se ky dizajn funksionon vetëm në konfigurimet në të cilat është aktivizuar modaliteti i menaxhimit automatik të bllokimit.



PËRBËRJE– kërkesa mbështet lidhjet TË MIRË/Djathtas, PLOTË, BRENDSHËM, që korrespondon me bashkimet në SQL – JOIN LEFT/RIGHT, OUTER JOIN, NINER JOIN.

Megjithatë, kur përdorni ndërtuesin e pyetjeve nuk do të jeni në gjendje ta bëni BASHKOHUNI DREJTË. Konstruktori thjesht do të shkëmbejë tabelat, por operatori do të jetë gjithmonë mëngjarash. Për këtë arsye, nuk do të shihni kurrë përdorimin e një lidhjeje të djathtë në 1C.

Në mënyrë sintaksore, lidhja duket si kjo:

ZGJIDH TABELËN1.Lidh AS Lidhje NGA Drejtoria.Direktoria1 AS Tabela1 LEFT JOIN Directory.Directory2 AS Table2 BY Table1.Atributet = Tabela2.Atributet

Gjuha e pyetjeve 1C nuk ka një operator për t'u bashkuar me një produkt kartezian (CROSS JOIN). Megjithatë, mungesa e një operatori nuk do të thotë që gjuha e pyetjes nuk e mbështet një lidhje të tillë. Nëse është e nevojshme, mund të bashkoni tabela si kjo:

ZGJIDH TABELEN1.Lidh AS Lidhje NGA Drejtoria.Direktoria1 AS Tabela1 LEFT JOIN Directory.Directory2 AS Table2 BY TRUE

Siç mund të shihet nga shembulli, çelësi i lidhjes është vendosur ME E VËRTETË, domethënë, çdo rresht i një tabele korrespondon me një rresht të një tjetri. Lloji i bashkimit (LEFT, RIGHT, FULL, INNER) nuk është i rëndësishëm nëse keni rreshta në të dyja tabelat, por nëse nuk ka rreshta në njërën nga tabelat (le të themi tabelën) - rezultati do të jetë i ndryshëm. Për shembull, kur përdorni TË BRENDSHËM rezultati i lidhjes do të jetë bosh. Duke përdorur MAJTAS DJATHTAS rezultati i bashkimit do të jetë ose nuk do të jetë të dhëna në varësi të cilës tabelë po i bashkojmë - me të dhëna ose jo. Duke përdorur PLOTE Të dhënat do të lidhen gjithmonë (natyrisht, vetëm nga një tabelë, pasi tjetra është bosh, zgjedhja e llojit të lidhjes varet nga detyra specifike e aplikacionit).

Një sugjerim i vogël vizual se si funksionojnë llojet e ndryshme të lidhjeve:



LIKE. Ndryshe nga operatori i ngjashëm SQL - LIKE, shablloni për LIKE mund të specifikohet duke përdorur vetëm disa karaktere speciale:

  • % (përqind): një sekuencë që përmban çdo numër karakteresh arbitrare;
  • _ (nënvizoj): një karakter arbitrar;
  • / - karakteri tjetër duhet të interpretohet si karakter i rregullt.

REZULTATET E SOFTVERIT Analogu SQL është operatori ROLLUP. Shembull i përdorimit të operatorit REZULTATET:

ZGJIDHni Produktet.Çmimi SI Çmimi, Produktet.Produkti SI Produkt NGA Drejtoria.Nomenklatura SI Produkte REZULTATET MESATAR (Çmimi) SIPAS produktit

Rezultati do të jetë si ky:

Shtrati

9833,333

Hekuri

Stilolaps

Domethënë, rezultatit i shtohet një rresht shtesë që përmban vlerën e fushës me të cilën kryhet grupimi dhe vlerën e funksionit të grumbullimit.

Puna me kërkesat e grupit

1C ju lejon të punoni me grupe kërkesash. Në një kërkesë grupi, tekstet e kërkesës ndahen me pikëpresje (;). Kërkesa e grupit 1C ekzekutohet në mënyrë sekuenciale. Shembull i tekstit të kërkesës së grupit:

SELECT Users.Link AS Link, Users.Parent AS Prind, Users.Name AS Emri FROM Directory.Users AS Users;
ZGJIDH Orarin e punës.Përdoruesi AS Përdorues, Orari i punës.Data AS Data, Orari i punës.Orari i punës SI Orari i punës NGA Regjistri Informacion.Orari i punës AS Orari i punës

Për të marrë rezultatin e të gjitha pyetjeve të përfshira në një paketë, duhet të përdorni metodën "ExecutePackage" të objektit të kërkesës, në vend të "Run". Kjo metodë ekzekuton të gjitha kërkesat në mënyrë sekuenciale. Rezultati i pyetjes është një grup rezultatesh për çdo pyetje në paketë, dhe sekuenca e vendosjes në grup është e njëjtë me sekuencën e pyetjeve në tekstin e paketës.

Kur merret parasysh një gjuhë e pyetjeve, vlen të përmendet një veçori e tillë si tabelat virtuale. Tabelat virtuale nuk janë të pranishme në bazën e të dhënave, ato janë një lloj mbështjellësi që ekzekutohet në anën e DBMS si një pyetje duke përdorur nënpyetje. Shembull i një pyetje 1C duke përdorur tabela virtuale:

SELECT RegisterLiabilitiesTurnovers.Liability AS Liability FROM RegisterAccumulations.RegisterLiabilities.Turnover() AS RegisterLiabilitiesTurnovers

Një pyetje e tillë për DBMS do të duket si kjo:

SEL ECT T1.Fld25931RRef FR OM (SELECT T2._Fld25931RRef AS Fld25931RRef, CAST(SUM(T2._Fld25936) AS NUMERIC(38, 8)) AS Fld25936Turnover(25931RRef)(3SUM. 8)) AS Fld25937Turnover_ FR OM dbo._AccumRgTn25938 T2 WH ERE ((T2._Fld949 = @P1)) AND ((T2._Fld25936 @P2 OSE T2._Fld25937 @P3Y)2593M (HP3YRF) (GROUP 2._Fld2 ) 5936 ) SI NUMERIK(38, 8))) 0.0 OSE (CAST(SUM(T2._Fld25937) SI NUMERIC(38, 8))) 0.0) T1>>>>

Mund të shihet se nuk duket si SQL, pasi ekziston një nënpyetje, grupim. Tabelat virtuale, në përgjithësi, janë "sheqer sintaksor", domethënë ato krijohen, në përgjithësi, për lehtësinë e zhvillimit të pyetjeve, në mënyrë që pyetjet të jenë më kompakte dhe më të lexueshme.

Vetëm regjistrat kanë tabela virtuale, por cilat tabela virtuale janë të disponueshme në një regjistër mund të shihen në projektuesin e pyetjeve.



Kur përdorni tabela virtuale, duhet të siguroni gjithmonë një kusht përzgjedhjeje. Përndryshe, mund të shfaqen probleme me performancën.



Në trupin e kërkesës duket kështu:

Regjistri i Detyrimeve të Akumulimit (, Operacioni = &Operacioni) Regjistri i detyrimeve

Për lehtësinë e shkrimit të pyetjeve, domethënë krijimin e teksteve të pyetjeve, në 1C ekziston një konstruktor që mund të thirret përmes menusë së kontekstit (butoni i djathtë i miut):



Në projektuesin e pyetjeve, mund të shihni një listë të plotë të funksioneve dhe operatorëve të mbështetur të gjuhës së pyetjeve.


Query Builder është një mjet vizual shumë fleksibël për krijimin e pyetjeve të çdo kompleksiteti. Është i disponueshëm vetëm në modalitetin e konfiguruesit. Në modalitetin Enterprise ekziston një e ashtuquajtur "Konsola e pyetjeve" - ​​ky është përpunim i jashtëm i dorëzuar në diskun ITS. Për një aplikacion të menaxhuar, tastiera e pyetjeve mund të shkarkohet nga its.1c.ru.

Një përshkrim i punës në projektuesin e pyetjeve është përtej qëllimit të këtij artikulli, kështu që nuk do të diskutohet në detaje.

Arsyet për performancën jo optimale të pyetjes

Më poshtë është një listë e arsyeve kryesore (por jo të gjitha) që çojnë në ekzekutimin e ngadaltë të pyetjes.

  • Përdorimi i lidhjeve me nënpyetje

Nuk rekomandohet të kryhet një bashkim me nënpyetjet duhet të zëvendësohen me tabela të përkohshme. Lidhja e nënpyetjeve mund të çojë në humbje të konsiderueshme të performancës dhe ekzekutimi i pyetjeve në DBMS të ndryshme mund të ndryshojë ndjeshëm në shpejtësi. Shpejtësia e ekzekutimit të pyetjeve të tilla është gjithashtu e ndjeshme ndaj statistikave në DBMS. Arsyeja për këtë sjellje është se optimizuesi DBMS nuk mund të përcaktojë gjithmonë saktë planin optimal të ekzekutimit të pyetjes, pasi optimizuesi nuk di asgjë se sa rreshta do të kthehet nënpyetja pas ekzekutimit të tij.

  • Përdorimi i tabelave virtuale në bashkimet e pyetjeve

Tabelat virtuale në nivelin DBMS ekzekutohen si nënpyetje, kështu që arsyet janë të njëjta si në paragrafin e parë.

  • Përdorimi i kushteve në një pyetje që nuk përshtaten me indekset ekzistuese

Nëse në kushtet e kërkesës (në operator KU ose kushtet e tabelës virtuale) përdor fusha që nuk janë të gjitha të përfshira në indeks, ky pyetje do të ekzekutohet duke përdorur skanimin e tabelës së konstruksionit SQL ose skanimin e indeksit (në tërësi ose pjesërisht). Kjo do të ndikojë jo vetëm në kohën e ekzekutimit të pyetjes, por gjithashtu do të vendoset një bllokim i tepërt S në rreshtat shtesë, i cili nga ana tjetër mund të çojë në përshkallëzim të bllokimit, domethënë e gjithë tabela do të bllokohet.

  • Përdorimi i OSE në kushtet e pyetjes

Përdorimi i operatorit logjik OSE në dizajn KU mund të rezultojë gjithashtu në një skanim tabele. Kjo ndodh sepse DBMS nuk mund ta përdorë saktë indeksin. Në vend të OSE ju mund të përdorni dizajnin KOMBINON GJITHÇKA.

  • Marrja e të dhënave përmes një pike për fushat e një lloji të përbërë

Nuk rekomandohet të merren vlera përmes një pike (në konstruksion ZGJIDH KU), sepse nëse atributi i objektit rezulton të jetë një tip kompleks, bashkimi do të ndodhë me secilën tabelë të përfshirë në këtë tip kompleks. Si rezultat, pyetja DBMS do të jetë dukshëm më e ndërlikuar, gjë që mund të pengojë optimizuesin të zgjedhë planin e saktë të ekzekutimit të pyetjes.

Nga baza e të dhënave sipas një kushti të caktuar. Për ta bërë këtë, në 1C 8.3 duhet të përdorni pyetje të mbivendosura.

Por duhet të kihet parasysh se në shumicën e rasteve, pyetjet e mbivendosura në 1C janë të padobishme pa i lidhur rezultatet e tyre me tabela të tjera. Në pothuajse çdo rast, një lidhje e tillë do të ngadalësojë shumë ekzekutimin e kërkesës në tërësi.

Një shembull i një pyetjeje të mbivendosur në një gjuhë pyetëse

Unë do të jap një shembull të një pyetjeje të mbivendosur për . Le të themi se duhet të mostrësojmë shumën e një bilanc të caktuar për klientët individualë në një datë të caktuar:

ZGJIDHNI
Mos disbursimi i bilanceve të pagesave,
Balancat e pagesave jo-dispetch.AmountBest
NGA

Merrni 267 mësime video në 1C falas:

LARTË BASHKOHET Regjistri i Akumulimit. Mosdisbursimi i pagesave AS Mosdisbursimi i pagesave
Software AttachmentRequest.LinkToRequestCustomers = PaymentsBalances të padisbursuara.Customer

Kur DBMS ekzekuton një pyetje të tillë, janë të mundshme veprime të pasakta nga optimizuesi, pasi është e vështirë të vendosësh për një plan për përpunimin e pyetjes. Kur një DBMS bashkon dy tabela, optimizuesi ndërton një algoritëm bazuar në llogaritjen e numrit të regjistrimeve në këto tabela.

Megjithatë, kur përdoret një nënpyetje, është shumë e vështirë të llogaritet numri i rekordeve të kthyera nga nënpyetja.

Cila është më mirë?

// Tabela e përkohshme
ZGJIDHNI
Konsumatorët.Lidhja SI Klientët
Skeda VEND Klientët
NGA
Drejtoria.Klientë AS Klientë
WHERE klientët.Lidhja B (&Klientë)
;

// Kërkesa kryesore
ZGJIDHNI
tabClients.Link,
Balancat e mospagesës. Sasia më e mirë,
NGA
tabKlientë SI tabKlientë
LIDHJA E MIRË Regjistrohu akumulimet e pashpërndara (.
,
Klienti B
(ZGJIDH
tabKlientë.Klientë
NGA
tabKlientë)) SI Dështimi për të paguar Bilancet e Pagesave
Skeda e softueritCustomers.Customers = PaymentsPaymentsBalances.Customers

Shikoni gjithashtu video-tutorialin rreth pyetjeve të ndërlidhura:

Tani optimizuesi e di paraprakisht sa regjistrime ka në tabelën e përkohshme dhe optimizon lehtësisht algoritmin e bashkimit të tabelës.

Nëse po filloni të mësoni programimin 1C, ju rekomandojmë kursin tonë falas (mos harroni

Projektuesi i pyetjeve në 1C 8.3 dhe 8.2 është një mjet i fuqishëm zhvillimi. Kjo ju lejon të kompozoni një tekst kërkese duke përdorur një mjedis të veçantë vizual. Kështu, për të krijuar një kërkesë 1C, nuk është e nevojshme të njihni gjuhën e integruar të pyetjes, mjafton të lundroni në ndërfaqen e thjeshtë dhe intuitive të projektuesit.

Ndërtuesi i pyetjeve është një grup skedash, secila prej të cilave është përgjegjëse për pjesën e vet të pyetjes. Pra, duke plotësuar skedën Tabelat dhe fushat Ne zgjedhim tabela nga të cilat pyetja 1C do të marrë të dhënat dhe fushat e këtyre tabelave të nevojshme për të zgjidhur një problem specifik. Mbushja në muraturë Kushtet vendosim kushte në tabelat e përzgjedhura për të zgjedhur prej tyre vetëm të dhënat që na nevojiten, e kështu me radhë.

Përshkrimi i projektuesit të pyetjeve në faqen zyrtare të internetit 1C 8: v8.1c.ru

Tabelat dhe fushat; ; ; ; ; ; Pyetjet e mbivendosura (në zhvillim).

Për të thirrur projektuesin e pyetjeve 1s 8 në kodin e programit, duhet të:

  • Krijo një kërkesë të re
Kërkesë = Kërkesë e re;
  • Vendosni një linjë teksti bosh të kërkesës
Kërkesë.Text = "";
  • Vendosni kursorin e miut midis thonjëzave dhe shtypni butonin e djathtë të miut. Në menynë e kontekstit që hapet, zgjidhni artikullin Konstruktori i pyetjeve dhe përgjigjuni po në pyetjen për krijimin e një kërkese të re. Nëse teksti i kërkesës tashmë është shkruar, atëherë duhet të klikoni kudo brenda tij dhe të telefononi konstruktorin ;

Le të shohim të gjitha skedat kryesore të ndërtuesit të pyetjeve duke përdorur shembuj të vegjël të rritjes së kompleksitetit. Kjo qasje do të lejojë një programues fillestar 1C të studiojë në mënyrë më efektive konstruktorin dhe të gjitha aftësitë e tij. Për shembuj ne do të përdorim konfigurimin Kontabiliteti 3.0.

Mesimi 1. Ndërtuesi i pyetjeve është rasti më i thjeshtë i përdorimit.

Detyrë: shkruani një kërkesë në drejtorinë e nomenklaturës, zgjidhni të gjithë nomenklaturën e drejtorisë.

Skeda të reja: Tabelat dhe fushat.

Mekanizmat e rinj: shikimi dhe redaktimi i tekstit të kërkesës duke përdorur butonin "Kërkesë".

Për të filluar krijimin e një kërkese, le të krijojmë një kërkesë të re dhe të thërrasim konstruktorin (siç është shkruar disa paragrafë më lart). Pas kësaj, dritarja e projektuesit do të hapet në skedën Tabelat dhe fushat.

Pjesa teorike e mësimit nr.1

Tab Tabelat dhe fushat përbëhet nga tre seksione:

Baza e të dhënave. Ky seksion paraqet të gjitha tabelat e bazës së të dhënave që mund të përdoren për të ndërtuar një pyetje;

Tabelat. Në këtë seksion, zgjidhen tabelat e nevojshme për këtë pyetje. Për t'i zhvendosur më pas nga seksioni bazën e të dhënave duhet:

  • Ose klikoni dy herë në tabelë;
  • Ose përdorni butonat ">" ose ">>".

Seksioni i mësipërm Tabelat Ka një numër butonash. Shumica e tyre do të diskutohen më në detaje në mësimet e mëposhtme. Tani për tani do të jap vetëm shpjegime të shkurtra.

  • Krijo një nënpyetje(Vija e kuqe). Projektuar për të krijuar një nënpyetje të re;
  • Krijoni një përshkrim të përkohshëm të tabelës(vija e verdhë). Ju lejon të specifikoni emrin e një tabele të përkohshme që ndodhet jashtë këtij pyetësori, ajo mund të përdoret gjithashtu për të kaluar një tabelë vlerash në pyetje;
  • Ndryshoni elementin aktual(Vija e gjelbër). Ju lejon të kaloni te nënpyetja e zgjedhur, tabela e përkohshme ose përshkrimi i përkohshëm i tabelës;
  • Hiq artikullin aktual(vija blu). Heq tabelën e zgjedhur nga tabelat e zgjedhura;
  • Zëvendësoni tabelën(vija blu). Hap dialogun për zëvendësimin e tabelës së zgjedhur. E dobishme nëse keni zgjedhur tabelën virtuale të regjistrit të gabuar, pasi pozicionimi ndodh në tabelën e përzgjedhur aktualisht në listë.
  • Opsionet e tabelës virtuale(vija vjollce). Hap parametrat e tabelës së regjistrit virtual.

Fushat. Ky seksion zgjedh fushat e tabelës nga seksioni i mëparshëm. Këto fusha do të jenë kolonat e tabelës ose përzgjedhja e marrë si rezultat i pyetjes. Ato nevojiten kryesisht për të marrë nga tabelat e përzgjedhura vetëm informacionin e nevojshëm në një rast të veçantë. Për t'i zhvendosur ato nga seksioni Tabelat e nevojshme:

  • Ose klikoni dy herë në fushë;
  • Ose përdorni butonat ">" ose ">>";
  • Ju gjithashtu mund të shtoni një fushë të re vetë, duke përdorur një shprehje arbitrare nga fushat e tabelave të zgjedhura dhe funksionet e gjuhës së pyetjes.

Seksioni i mësipërm Fushat Ka një numër butonash. Krijimi i fushave duke përdorur shprehje arbitrare do të diskutohet më në detaje në mësimet e mëposhtme. Tani për tani do të jap vetëm shpjegime të shkurtra.

  • Shtoni(Vija e gjelbër). Projektuar për të shtuar një fushë të re duke përdorur redaktuesin e shprehjes së lirë;
  • Ndryshoni elementin aktual(Vija e kuqe). Ju lejon të ndryshoni fushën e zgjedhur duke përdorur redaktuesin;
  • Fshi rrymën(vija blu). Heq fushën e zgjedhur nga lista.

Pjesa praktike e mësimit nr.1

Ne kemi trajtuar teorinë e nevojshme për të përfunduar detyrën e dhënë në këtë mësim. Më lejoni t'ju kujtoj se si tingëllon: shkruani një kërkesë në drejtorinë e nomenklaturës, zgjidhni të gjithë nomenklaturën e drejtorisë.

Le të fillojmë të krijojmë një kërkesë për artikuj:

  • Le të krijojmë një kërkesë të re dhe të hapim konstruktorin duke përdorur metodën e specifikuar në fillim të mësimit;
  • Në kapitull Baza e të dhënave, le të hapim një temë Drejtoritë dhe ne do të gjejmë një udhëzues atje Nomenklatura;
  • Zgjidhni atë dhe përdorni butonin ">" për ta zhvendosur atë në seksion Tabelat;
  • Në kapitull Tabelat hapni drejtorinë e nomenklaturës duke përdorur ikonën "+";
  • Në listën e fushave që hapet, gjeni fushën Lidhje dhe zhvendoseni atë në seksion Fushat duke përdorur butonin ">".
  • Kërkesa e artikullit është gati, klikoni butonin "OK" në fund të dritares së projektuesit.

Le të shohim se çfarë është pyetjet e mbivendosura në dhe pse janë të nevojshme.
Shpesh ekziston një situatë kur duhet të kryhen disa veprime të njëpasnjëshme në një tryezë. Një shembull mjaft ilustrues është kur ju duhet fillimisht, dhe më pas vendosni disa kushte në një tabelë të grupuar, ose lidhni atë me një tabelë tjetër. Në raste të tilla, ata vijnë në shpëtim pyetjet e mbivendosura.

Një pyetje e mbivendosur praktikisht nuk është e ndryshme nga një pyetje e zakonshme. Është mbyllur në kllapa dhe pothuajse të gjitha metodat dhe funksionet e gjuhës së pyetjeve 1C janë të disponueshme në të. Dhe për pyetjen mëmë, të gjitha fushat e nënpyetjes janë të disponueshme.
Struktura e pyetjes së mbivendosur më primitive duket si kjo:

SELECT FROM (SELECT FROM) AS NestedQuery

Sigurisht, në këtë formë, përdorimi i një pyetjeje të ndërthurur nuk ka kuptim, sepse Mund të zgjidhni menjëherë fushat e kërkuara pa përdorur fole. Gjithçka këtu është jashtëzakonisht e thjeshtuar për lehtësinë e të kuptuarit.

Tani le të shohim të gjitha sa më sipër duke përdorur një shembull.
Le të kemi një tabelë EmployeesDivisions:

Dhe ne duam të zgjedhim nga kjo tabelë të gjitha departamentet ku punon më shumë se një punonjës.

SELECT EmployeesDivisions.Division AS Division, NUMBER(EmployeesDivisions.Employee) AS Number ofEmployees FROM EmployeesDivisions AS EmployeesDivisions GROUP BY EmployeesDivisions.Division

Nëse e drejtojmë këtë pyetje, si rezultat do të marrim tabelën e mëposhtme

Hapi i dytë është vendosja e një kufiri në numrin e punonjësve në këtë tabelë. Për ta bërë këtë, ne do ta bëjmë pyetjen e mësipërme të ndërthurur dhe do të shkruajmë kushtin përkatës në pyetjen më të lartë

SELECT NestedQuery.Njësi AS Njësi FROM (SELECT EmployeesUnits.Unit AS Unit, QUANTITY(EmployeesUnits.Employee) AS Numri i Punonjësve FROM EmployeesUnits AS EmployeesUnits GROUP BY EmployeesUnits.United es > 1

Kështu, rezultati i pyetjes përfundimtare do të jetë si më poshtë

Për të qenë të drejtë, vlen të përmendet se i njëjti rezultat mund të arrihet duke përdorur funksionin DUKE Gjuha e pyetjes 1C, si dhe përdorimi i tabelave të përkohshme.
Në praktikë, sigurisht që do të hasni pyetje më komplekse të ndërthurura që mund të përdorin si tabela ashtu edhe tabela. Mund të ketë gjithashtu disa nivele foleje.

Vendosa të jap kontributin tim dhe të përshkruaj ato veçori të gjuhës që nuk u diskutuan në artikujt e mësipërm. Artikulli u drejtohet zhvilluesve fillestarë.

1. Dizajni “IZ”.

Për të marrë të dhëna nga baza e të dhënave, nuk është aspak e nevojshme të përdoret ndërtimi "FROM".
Shembull: Ne duhet të zgjedhim të gjitha informacionet për bankat nga drejtoria e bankave.
Kërkesë:

SELECT Directory.Banks.*

Zgjedh të gjitha fushat nga drejtoria e Bankave. Dhe është e ngjashme me kërkesën:

SELECT Bankat.* FROM Directory.Banks AS Banks

2. Renditja e të dhënave sipas fushës së referencës

Kur duhet të organizojmë të dhënat e pyetësorit sipas llojeve primitive: "String", "Number", "Date", etj., atëherë gjithçka zgjidhet duke përdorur konstruktin "ORDER BY" nëse duhet të renditni të dhënat sipas një fushe referimi? Fusha e referencës është një lidhje, një identifikues unik, d.m.th. Përafërsisht, disa grupe arbitrare karakteresh dhe renditje të zakonshme mund të prodhojnë një rezultat që nuk pritet plotësisht. Për të porositur fushat e referencës, përdoret ndërtimi "AUTO ORDER". Për ta bërë këtë, së pari duhet të renditni të dhënat drejtpërdrejt sipas llojit të referencës duke përdorur konstruktin "ORDER BY" dhe më pas konstruktin "AUTO ORDER".

Në këtë rast, për dokumentet, renditja do të bëhet në rendin "Data->Numër", për librat e referencës në "Pamje kryesore". Nëse renditja nuk ndodh sipas fushave të referencës, atëherë përdorimi i konstruksionit "AUTO ORDER" nuk rekomandohet.

Në disa raste, konstrukti "AUTO ORDER" mund të ngadalësojë procesin e përzgjedhjes. Në mënyrë të ngjashme, ju mund të rishkruani pa porositur automatikisht dokumente:

3. Marrja e një paraqitjeje teksti të një lloji referimi. Dizajni "PREZANTIM".

Kur duhet të shfaqni një fushë të një lloji referimi, për shembull, fusha "Banka", e cila është një lidhje me një element të drejtorisë "Bankat", duhet të kuptoni se kur shfaqni këtë fushë, një nënpyetje në " Drejtoria e Bankave" do të ekzekutohet automatikisht për të marrë një pamje të drejtorisë. Kjo do të ngadalësojë prodhimin e të dhënave. Për të shmangur këtë, duhet të përdorni konstruksionin "PREZANTIM" në kërkesë në mënyrë që të merrni menjëherë një paraqitje të objektit dhe më pas ta shfaqni atë për shikim.

Në sistemin e përbërjes së të dhënave, ky mekanizëm përdoret si parazgjedhje, por kur krijoni paraqitje në qeliza, duhet të specifikoni paraqitjen e fushës së referencës dhe, për shembull, të vendosni vetë lidhjen në transkript.

4. Kushti për marrjen e të dhënave sipas një shablloni.

Për shembull, ju duhet të merrni telefona celularë të punonjësve të formularit (8 -123- 456-78-912). Për ta bërë këtë, duhet të vendosni kushtin e mëposhtëm në kërkesë:

SELECT Punonjës.Emri, Punonjës.Telefoni AS Telefon NGA Direktoria.Punonjësit AS Punonjës WHERE Phone LIKE "_-___-___-__-__"

Karakteri "_" është një karakter shërbimi dhe zëvendëson çdo karakter.

5. Përdorimi i njëkohshëm i totaleve dhe grupimeve.


Totalet shpesh përdoren në lidhje me grupimet në këtë rast, funksionet e përgjithshme mund të mos specifikohen në total.

SELECT Ofrimi i Sherbimeve.Organizimi AS Organizimi, Ofrimi i Sherbimeve.Nomenklatura AS Nomenklature, SUM(Ofrimi i Sherbimeve.Shuma e Dokumentit) AS Shuma e Dokumentit FROM Document.Organizimi i Sherbimeve AS Ofrimi i Sherbimeve GROUP BY Ofrimi i Sherbimeve.Organizimi, Ofrimi i Shërbimeve.NOmenklatura REZULTATET SIPAS TË PËRGJITHSHME, Organizata, nomenklatura

Në këtë rast, pyetja do të kthehet pothuajse njësoj si pyetja e mëposhtme:

SELECT Ofrimi i Sherbimeve.Organizata AS Organizimi, Ofrimi i Sherbimeve.Nomenklatura AS Nomenklatura, Ofrimi i Sherbimeve.Shuma e Dokumentit AS Shuma e Dokumentit FROM Document.Sigurimi i Sherbimeve AS Ofrimi i Sherbimeve REZULTATET SHUMIA (Shuma e Dokumentit) NGA PERGJITHSHME Nomenklatura

Vetëm pyetja e parë do të rrëzojë të dhënat me të njëjtën nomenklaturë.

6. Dereferencimi i fushave.

Referimi i fushave përmes një pike quhet operacioni i çreferencimit të fushës së referencës. Për shembull Pagesa.Organizata.Njsia Administrative. Në këtë rast, në fushën e referencës “Organizimi” i dokumentit “Pagesa” i referohet një tabelë tjetër “Organizatat”, në të cilën do të merret vlera e atributit “Njësi Administrative”. Është e rëndësishme të kuptohet se kur hyni në fusha përmes një pike, platforma krijon në mënyrë implicite një nënpyetje dhe bashkon këto tabela.

Kërkesë:

Mund të përfaqësohet si:

SELECT Payment.Link, Payment.Organization, Payment.Organization, Organizations. Administrative Unit FROM Document.Payment AS Pagesa LEFT JOIN Directory.Organizations AS Organizations Software Payment.Organization = Organizations.Link

Kur çreferencohen fushat e referencës të një lloji të përbërë, korniza përpiqet të krijojë bashkime të nënkuptuara me të gjitha tabelat që janë pjesë e llojit të asaj fushe. Në këtë rast, pyetja nuk do të jetë optimale Nëse dihet qartë se çfarë lloj fushe është, është e nevojshme të kufizohen fushat e tilla sipas llojit me një konstrukt EXPRESS().

Për shembull, ekziston një regjistër akumulimi "Pagesat e pashpërndara", ku disa dokumente mund të veprojnë si regjistrues. Në këtë rast, është e gabuar të merren vlerat e detajeve të regjistruesit në këtë mënyrë:

SELECT UnallocatedPayments.Register.Date, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

ju duhet të kufizoni llojin e fushës së përbërë në logger:

SELECT EXPRESS(Pagesat e pandara. Regjistrohu AS Document.Payment).Data, ..... FROM RegisterAccumulation.Payments Unallocated AS UnallocatedPayments

7. Ndërtimi "KU"

Me një bashkim majtas të dy tabelave, kur vendosni një kusht "KU" në tabelën e djathtë, do të marrim një rezultat të ngjashëm me rezultatin me një bashkim të brendshëm tabelash.

Shembull. Është e nevojshme të zgjidhen të gjithë Klientët nga Direktoria e Klientëve dhe për ata klientë që kanë një dokument pagese me vlerën e atributit "Organization" = &Organization, të shfaqet dokumenti "Pagesa", për ata që nuk kanë, mos e shfaqin atë.

Rezultati i pyetjes do të kthejë rekorde vetëm për ata klientë që kishin pagesë sipas organizatës në parametrin dhe do të filtrojë klientët e tjerë. Prandaj, së pari duhet të merrni të gjitha pagesat për organizatën "kështu dhe të tillë" në një tabelë të përkohshme dhe më pas ta lidhni atë me drejtorinë "Klientë" duke përdorur një bashkim majtas.

SELECT Payment.Link AS Payment, Payment.Aksioner AS Klient PLACE toPages FROM Document.Pagement AS Pagesë KU Pagesa.Dega = &Dega; ///////////////////////////////////////////////////////////////// ////////////////////////// SELECT Klientët.Link AS Klient, ISNULL(tPayment.Payment, "") AS Pagesa NGA Drejtoria .Klientët AS Klientët LËNË LIDHJE TË MIRË pagesat AS SOFTWARE për pagesat Clients.Link = toppayments.Client

Ju mund ta shmangni këtë gjendje në një mënyrë tjetër. Është e nevojshme të vendoset një kusht "KU" drejtpërdrejt në marrëdhëniet midis dy tabelave. Shembull:

SELECT Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers LIDHJA LEFT Document.Payment AS Payment Software (Clients.Link = Payment.Client AND Payment.Client.Emri LIKE "Sugar Packet",ClientsLinkY) Klienti.Link. Lidhje

8. Bashkohet me Tabelat e Nested dhe Virtuale

Pyetjet e mbivendosura shpesh është e nevojshme për të marrë të dhëna bazuar në disa kushte. Nëse më pas i përdorni ato në lidhje me tabela të tjera, kjo mund të ngadalësojë në mënyrë kritike ekzekutimin e pyetjes.

Për shembull, ne duhet të marrim shumën e bilancit që nga data aktuale për disa klientë.

SELECT UnallocatedPaymentsBalances.Customer, UnallocatedPaymentsBalances.AmountBalance FROM (SELECT Clients.Link AS Link FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Clients)) AS NestedQueryRegisterAlocatedAloculations yments BY Nested nyRequest.Link = Balancat e paalokuara të pagesave. Klienti

Gjatë ekzekutimit të një pyetjeje të tillë, optimizuesi i DBMS mund të bëjë gabime kur zgjedh një plan, gjë që do të çojë në ekzekutimin jo optimal të pyetjes. Kur bashkoni dy tabela, optimizuesi DBMS zgjedh një algoritëm të bashkimit të tabelave bazuar në numrin e regjistrimeve në të dyja tabelat. Nëse ka një pyetje të mbivendosur, është jashtëzakonisht e vështirë të përcaktohet numri i rekordeve që do të kthejë pyetja e mbivendosur. Prandaj, duhet të përdorni gjithmonë tabela të përkohshme në vend të pyetjeve të mbivendosura. Pra, le ta rishkruajmë kërkesën.

ZGJIDH Klientët.Lidhja AS VENDI Lidhje tKlientët NGA Drejtoria.Klientët AS Klientë WHERE
Klientët.Lidhja B (&Klientët) ; ///////////////////////////////////////////////////////////////// ////////////////////////// SELECT tClients.Link, UnallocatedPaymentsRemains.Amount Remaining, FROM tClients AS tKlientët LËNË SHQIPTAR RegjistrohuAkumulimet.UallokuaraPayments.Balancat e klientëve IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

Në këtë rast, optimizuesi do të jetë në gjendje të përcaktojë se sa rekorde përdor tabela e përkohshme tClients dhe do të jetë në gjendje të zgjedhë algoritmin optimal për bashkimin e tabelave.

Tabelat virtuale , ju lejon të merrni të dhëna praktikisht të gatshme për shumicën e detyrave të aplikuara (Fetë e së Parës, Fetë e fundit, Mbetet, Qarkullimet, Mbetjet dhe Qarkullimet) Fjala kyçe këtu është virtuale. Këto tabela nuk janë fizike, por janë të përpiluara nga sistemi në fluturim, d.m.th. Me rastin e marrjes së të dhënave nga tabelat virtuale, sistemi mbledh të dhëna nga tabelat e regjistrit përfundimtar, mbledh, grupon dhe ia lëshon përdoruesit.

Ato. Kur lidheni me një tabelë virtuale, bëhet një lidhje me një nënpyetje. Në këtë rast, optimizuesi DBMS mund të zgjedhë gjithashtu një plan lidhjeje jo optimale. Nëse pyetja nuk gjenerohet mjaft shpejt dhe pyetja përdor bashkime në tabela virtuale, atëherë rekomandohet të zhvendoset qasja në tabelat virtuale në një tabelë të përkohshme dhe më pas të bëhet një bashkim midis dy tabelave të përkohshme. Le të rishkruajmë kërkesën e mëparshme.

ZGJIDH Klientët.Lidhja AS VENDI Lidhje tKlientët NGA Drejtoria.Klientët AS Klientë INDEKSI NGA Lidhja WHERE
Klientët.Lidhja B (&Klientët) ; ///////////////////////////////////////////////////////////////// /////////////////////////// ZGJIDHni pagesat e paalokuara.AmountBalance, UnallocatedPayments.Client AS Klient PLACE balancat FROM RegisterAcumulations.Payments Unallocated.Balances(, Klienti B ( ZGJIDHni tClients Lidhje NGA tClients)) AS PaalokuarPaymentsBalances; ///////////////////////////////////////////////////////////////// ////////////////////////// ZGJEDHNI tClients.Link, teRemainders.Sasia e mbetur AS Shuma e mbetur NGA tKlientët AS tKlientët LEFT JOIN për të mbeturinat AS mbetjet BY tnkC. = t Mbetjet.Klienti

9.Kontrollimi i rezultatit të kërkesës.

Rezultati i pyetjes mund të jetë bosh për të kontrolluar vlerat boshe, përdorni konstruktin e mëposhtëm:

ResRequest = Kërkesë.Execute(); Nëse resQuery.Empty() Pastaj Kthehu; fundNëse;

Metoda Bosh () duhet të përdoret para metodave Zgjidhni () ose Shkarko (), pasi marrja e koleksionit kërkon kohë.

Nuk është një zbulim për askënd që është jashtëzakonisht e padëshirueshme të përdoren pyetje në një lak. Kjo mund të ndikojë në mënyrë kritike në kohën e funksionimit të një funksioni të caktuar. Është shumë e dëshirueshme që të merren të gjitha të dhënat në kërkesë dhe më pas të përpunohen të dhënat në një cikli. Por ndonjëherë ka raste kur bëhet e pamundur zhvendosja e kërkesës jashtë ciklit. Në këtë rast, për optimizim, mund të zhvendosni krijimin e pyetjes jashtë ciklit, dhe në ciklin, të zëvendësoni parametrat e nevojshëm dhe të ekzekutoni pyetjen.

Kërkesë = Kërkesë e re; Query.Text = "ZGJIDH | Klientët.Lidhja, | Klientët.Data e lindjes |NGA | Drejtoria.Klientët SI Klientë | KU | Klientët.Lidhja = &Klient"; Për çdo rresht FROM TableClients Loop Query.SetParameter("Klient", Klient); QueryResult = Query.Execute().Select(); Cikli i Fundit;

Kjo do ta shpëtojë sistemin nga kontrollimi i sintaksës së kërkesës në një lak.

11. Ndërtim “HAVING”.

Një dizajn që është mjaft i rrallë në kërkesa. Ju lejon të vendosni kushte për vlerat e funksioneve agregate (SHUMË, MINIMUM, MESATAR, etj.). Për shembull, ju duhet të zgjidhni vetëm ata klientë, shuma e pagesës së të cilëve në shtator ishte më shumë se 13,000 rubla. Nëse përdorni kushtin "WHERE", fillimisht do t'ju duhet të krijoni një tabelë të përkohshme ose një pyetje të ndërthurur, të gruponi regjistrimet atje sipas shumës së pagesës dhe më pas të aplikoni kushtin. Ndërtimi "HAVING" do të ndihmojë në shmangien e kësaj.

SELECT Payment.Customer, AMOUNT(Payment.Amount) AS Amount FROM Document.Payment AS Payment WHERE MUAJ(Data.Payment) = 9 GROUP BY Payment.Customer HAVING AMOUNT(Payment.Smount) > 13000

Në konstruktor, për ta bërë këtë, thjesht shkoni te skeda "Kushtet", shtoni një kusht të ri dhe kontrolloni kutinë e kontrollit "Custom". Pastaj thjesht shkruani Shuma (Pagesa.Shuma) > 13000


12. Vlera NULL

Unë nuk do të përshkruaj këtu parimet e logjikës me tre vlera në bazën e të dhënave, ka shumë artikuj mbi këtë temë. Vetëm shkurtimisht se si I PAVLEFSHËM mund të ndikojë në rezultatin e pyetjes. Vlera NULL nuk është në fakt një vlerë, dhe fakti që vlera është e papërcaktuar është i panjohur. Prandaj, çdo operacion me NULL kthen NULL, qoftë mbledhje, zbritje, pjesëtim apo krahasim. Një vlerë NULL nuk mund të krahasohet me një vlerë NULL sepse ne nuk dimë se çfarë të krahasojmë. Ato. të dyja këto krahasime janë: NULL = NULL, NULL<>NULL nuk është e vërtetë apo e rreme, është e panjohur.

Le të shohim një shembull.

Për ata klientë që nuk kanë pagesa, duhet të afishojmë fushën “Sign” me vlerën “Nuk ka pagesa”. Për më tepër, ne e dimë me siguri që kemi klientë të tillë. Dhe për të pasqyruar thelbin e asaj që shkrova më lart, le ta bëjmë në këtë mënyrë.

ZGJIDH "Nuk ka pagesa" SI Atribut, NULL AS Toppagesat e VENDIT të dokumentit; ///////////////////////////////////////////////////////////////// ///////////////////////// ZGJIDH Klientët.Lidhja AS Klient, Pagesa.Lidhja SI Pagesa VENDOSI tClientPayment NGA Drejtoria.Klientët AS Klientët LËNË Dokumentin e LIDHJES. Pagesa AS Software Payment Clients.Link = Pagesa.Aksionar; ///////////////////////////////////////////////////////////////// //////////////////////// ZGJEDHNI tClientPayment.Client NGA tClientPayment AS tClientPayment INTERNAL JOIN tPayment AS tPaguaj NGA tClientPayment.Pagesa = tClientPayment

Kushtojini vëmendje tabelës së dytë të përkohshme tClientPayment. Me bashkimin e majtë zgjedh të gjithë klientët dhe të gjitha pagesat për këta klientë. Për ata klientë që nuk kanë pagesa, fusha “Pagesa” do të jetë NULL. Sipas logjikës, në tabelën e parë të përkohshme “tPayments” caktova 2 fusha, njëra prej tyre NULL, rreshtin e dytë “Nuk ka pagesa”. Në tabelën e tretë, unë lidh tabelat "tClientPayment" dhe "tPayment" duke përdorur fushat "Pagesë" dhe "Dokument" me një bashkim të brendshëm. Dimë që në tabelën e parë fusha “Dokument” është NULL, kurse në tabelën e dytë, ata që nuk kanë pagesa në fushën “Pagesa” janë gjithashtu NULL. Çfarë do të na rikthejë një lidhje e tillë? Por nuk do të kthejë asgjë. Sepse krahasimi NULL = NULL nuk vlerësohet në True.

Në mënyrë që kërkesa të kthejë rezultatin e pritur, le ta rishkruajmë atë:

ZGJEDH "Nuk ka pagesa" SI Atribut, VLERA(Document.Payment.EmptyLink) AS VENDI I dokumentit tePagesat; ///////////////////////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(Payment.Link, VALUE(Document.Payment.EmptyLink)) SI Pagesa PUT tClientPayment FROM Directory.Klientët SI Klientë Dokumenti LIDHJA E LETË.Pagesa SI Pagesa NGA Klientët.Lidhja = Pagesa.Aksionari; ///////////////////////////////////////////////////////////////// //////////////////////// ZGJEDHNI tClientPayment.Client NGA tClientPayment AS tClientPayment INTERNAL JOIN tPayment AS tPaguaj NGA tClientPayment.Pagesa = tClientPayment

Tani, në tabelën e dytë të përkohshme, ne kemi treguar se nëse fusha "Pagesa" është NULL, atëherë kjo fushë = një lidhje boshe me dokumentin e pagesës. Në tabelën e parë ne gjithashtu zëvendësuam NULL me një referencë boshe. Tani lidhja përfshin fusha jo NULL dhe kërkesa do të kthejë rezultatin e pritur.

Të gjitha kërkesat e përfshira në artikull pasqyrojnë situatat që do të doja të merrja në konsideratë dhe asgjë më shumë. RRETH Ato mund të mos jenë delirante ose nënoptimale, gjëja kryesore është që ato pasqyrojnë thelbin e shembullit.

13. Një tipar i padokumentuar i dizajnit "ZGJEDHJA KUR...PËSHTJE...FUND".

Në rastin kur është e nevojshme të përshkruhet ndërtimi "Kushtet" në kërkesë, ne përdorim sintaksën standarde:

ZGJIDH ZGJEDHJEN WHEN Users.Name = "Vasya Pupkin" THEN "Punonjësi ynë i preferuar" ELSE "Ne nuk e dimë këtë" FUND AS Field1 FROM Directory.Përdoruesit AS Përdorues

Por, çka nëse, për shembull, duhet të marrim emrin e muajit në një kërkesë? Shkrimi i një ndërtimi të madh në një kërkesë është i shëmtuar dhe kërkon shumë kohë, kështu që kjo formë e shkrimit më lart mund të na ndihmojë:

ZGJIDH MUAJIN(US_CalculationConsumption_TurnoverSchedule.CalculationPeriod) WHEN 1 PASTAJ "Janar" WHEN 2 PASTA "shkurt" WHEN 3 PASTAJ "Mars" WHEN 4 PASTAJ "Prill" WHEN 5 PASTAJ "KURËN "THENJHENHY" 8 PASTAJ "Gusht" KUR 9 PASTAJ "Shtator" KUR 10 PASTA "Tetor" KUR 11 PASTA "Nëntor" KUR 12 PASTAJ "Dhjetor" PËRFUNDON SI një muaj

Tani dizajni duket më pak i rëndë dhe është i lehtë për t'u kuptuar.

14. Ekzekutimi në grup i një kërkese.


Për të mos shumëzuar kërkesat, mund të krijoni një kërkesë të madhe, ta ndani në paketa dhe të punoni me të.
Për shembull, më duhet të marr fushat e mëposhtme nga drejtoria "Përdoruesit": "Data e lindjes" dhe rolet e disponueshme për çdo përdorues. ngarkoni këtë në pjesë të ndryshme tabelare në formular. Sigurisht, ju mund ta bëni këtë me një kërkesë, atëherë do t'ju duhet të përsërisni regjistrimet ose t'i fshini ato, ose mund ta bëni këtë:

SELECT Users.Link AS Emri i plotë, Përdoruesit.Data e lindjes, Përdoruesit.Roli PUT vtUsers FROM Directory.Users AS Users; ///////////////////////////////////////////////////////////////// ///////////////////////// ZGJIDHni tueUsers.Emri i plotë, tueUsers.Data e lindjes NGA tueUsers AS tueUsers GRUPI SIPAS tueUsers.emri i plotë, tueUsers . Data e lindjes; ///////////////////////////////////////////////////////////////// //////////////////////// ZGJIDHni wUsers.Emri i plotë, wUsers.Role FROM Users AS WUsers GROUP BY Users.Emri i plotë, wUsers të Lindjes

tPackage = Request.ExecutePackage();

TP_Data e lindjes = tPaketa.Ngarko();
TP_Rolet = tPaketa.Shkarko();

Siç mund ta shohim, pyetja mund të ekzekutohet në një grup dhe rezultati mund të përpunohet si një grup. Në disa raste është shumë i përshtatshëm.

15. Kushtet në një kërkesë grupi

Për shembull, kemi një kërkesë grupi, ku fillimisht marrim fushat: “Emri, data e lindjes, kodi” nga direktoria “Përdoruesit” dhe duam të marrim regjistrime me kushtet për këto fusha nga direktoria “Individët”.

SELECT Users.Individual.Name AS Emri, Users.Individual.Data e lindjes AS Data e lindjes, Users.Individual.Code AS Code PLACE vtUsers FROM Directory.Users AS Users; ///////////////////////////////////////////////////////////////// /////////////////////// SELECT Individuals FROM Individuals AS Individuals

Ju mund të vendosni kushte si kjo:

WHERE Individuals.Code IN (SELECT tueUsers.Code FROM tueUsers) AND Individuals.Name IN (SELECT tueUsers.Code FROM tueUsers) DHE Individuals.BirthDate IN (ZGJEDH tueUsers.DateUsers FROM tue)

Dhe ju mund ta bëni këtë si kjo:

WHERE (Individuals.Code, Individuals.Name, Individuals.Date of Birth) IN (ZGJIDHni tueUsers.Code, tueUsers.Name, tueUsers.Data e lindjes FROM tueUsers)

Për më tepër, është e nevojshme të ruani rendin.

16. Thirrja e ndërtuesit të pyetjeve për "kusht" në një kërkesë grupi

Kur është e nevojshme të vendosni një kusht, si në shembullin e mësipërm, mund të harroni se si thirret kjo apo ajo fushë në tabelën virtuale.
Për shembull, duhet të vendosni një kusht në fushën "Data e lindjes", dhe në tabelën virtuale kjo fushë quhet "Data e lindjes së debitorit", dhe nëse harroni emrin, do të duhet të dilni nga redaktimi i kushtit pa duke ruajtur dhe shikoni emrin e fushës. Për të shmangur këtë, mund të përdorni teknikën e mëposhtme.

Është e nevojshme të vendosni kllapa pas konstruksionit "B" dhe të lini një hapësirë ​​(hapësirë) boshe midis kllapave, zgjidhni këtë hapësirë ​​dhe thirrni konstruktorin e pyetjes. Projektuesi do të ketë akses në të gjitha tabelat e pyetjes së grupit. Teknika funksionon si në tabelat e regjistrave virtualë ashtu edhe në skedën "Kushtet". Në rastin e fundit, duhet të kontrolloni kutinë "P (kusht arbitrar)" dhe të futni modalitetin e redaktimit "F4".

Pyetjet shpesh bëheshin menjëherë dhe ato thjesht shërbejnë për të ilustruar "teknikat" që po shqyrtoja.

Doja të shikoja përdorimin e indekseve në pyetje, por kjo është një temë shumë e gjerë. Do ta vendos në një artikull të veçantë, ose do ta shtoj këtu më vonë.

upd1. Pikat 11,12
upd2. Pikat 13,14,15,16

Librat e përdorur:
Gjuha e pyetjes "1C: Enterprise 8" - E.Yu. Khrustaleva
Zhvillimi profesional në sistemin 1C: Enterprise 8."

pikëpamjet