1c valg i hvor-forespørselen. Hente verdien av et felt av en kompleks type ved å bruke en prikk

1C-spørringsspråket er en av hovedforskjellene mellom versjon 7.7 og 8. En av de viktigste punktene i studiet av 1C programmering er et spørrespråk. I 1C 8.3 er søk de kraftigste og effektivt verktøy mottar data. Spørringsspråket lar deg hente informasjon fra databasen på en praktisk måte.

Syntaksen i seg selv minner mye om klassisk T-SQL, bortsett fra at i 1C, ved å bruke spørringsspråket, kan du kun motta data ved å bruke Select-konstruksjonen. Språket støtter også mer komplekse konstruksjoner, for eksempel (forespørsel innenfor en forespørsel). Spørringer i 1C 8 kan skrives på både kyrillisk og latin.

I denne artikkelen vil jeg prøve å snakke om hovednøkkelordene i 1C-spørringsspråket:

velge
tillatt
diverse
uttrykke
først
for endring
betydning
verditype (og REFERANSE-operator)
valg
gruppe av
å ha
ISNULL
Ja NULL
tilkoblinger - høyre, venstre, intern, full.

I tillegg til noen små triks av 1C-språket, som du kan bruke til å konstruere forespørselsteksten optimalt.

For å feilsøke spørringer i 1C 8.2-systemet, er det gitt et spesialverktøy - spørringskonsollen. Du kan se beskrivelsen og laste den ned ved å bruke lenken -.

La oss se på de viktigste og mest interessante operatørene av 1C-spørringsspråket.

PLUKKE UT

I spørringsspråket 1C Enterprise 8 begynner enhver spørring med et nøkkelord VELGE. I 1C-språket er det ingen UPDATE, DELETE, CREATE TABLE, INSERT-konstruksjoner utført i objektteknologi. Hensikten er kun å lese data.

For eksempel:

VELGE
Gjeldende katalog.navn
FRA
Directory.Nomenclature AS Current Directory

Spørringen vil returnere en tabell med varenavn.

Nær strukturen VELGE du kan finne nøkkelord FOR ENDRING, TILLATT, DIVERSE, FØRST …

TILLATT— velger kun poster fra tabellen som gjeldende bruker har rettigheter til.

DIVERSE— betyr at resultatet ikke vil inneholde dupliserte linjer.

UTVALG (CASE)

Svært ofte blir dette designet undervurdert av programmerere. Et eksempel på bruken:

Gjeldende katalog.navn,

NÅR Current Directory.Service DA

"Service"

SLUTT HVORDAN DU SE Nomenklatur

Directory.Nomenclature AS Current Directory

Eksemplet kommer tilbake i feltet "Type nomenklatur". tekstverdi- "Produkt" eller "Tjeneste".

HVOR

Utformingen av 1C-spørringsspråket, som lar deg pålegge de mottatte dataene valg. Vær oppmerksom på at systemet mottar all data fra serveren, og først da velges den basert på denne parameteren.

VELGE
Directory.Name
FRA
Current Directory.Nomenclature AS Current Directory
WHERE CurrentDirectory.Service = TRUE

I eksemplet velger vi poster der verdien av «Service»-attributtet er satt til «True». I i dette eksemplet Man kan klare seg med følgende tilstand:

"HVOR ER TJENESTEN"

I hovedsak velger vi rader der uttrykket etter nøkkelordet er lik "True".

Du kan bruke direkte betingelser i uttrykk:

WHERE-kode = "005215"

Ved å bruke "VALUE()"-operatoren i betingelsene, bruk tilgang til forhåndsdefinerte elementer og oppregninger i en 1C-forespørsel:

WHERE Varetype = Verdi(Opptelling.Varetyper.Produkt)

Tidsverdier kan spesifiseres som følger:

WHERE Kvitteringsdato > DATOTIME(2012,01,01):

Oftest er betingelser spesifisert som parametere som sendes til forespørselen:

Få 267 videotimer på 1C gratis:

WHERE NomenclatureGroup= &NomenclatureGroup

En betingelse kan pålegges typen attributt hvis den kompositt type:

Hvis du trenger å begrense valg fra en liste med verdier eller en matrise, kan du gjøre følgende:

HVOR er akkumuleringsregisteret B (&Liste over dokumenter for utvelgelse).

Tilstanden kan også være kompleks, bestående av flere tilstander:

WHERE Mottaksdato > DATOTIME(2012,01,01) AND NomenclatureGroup= &NomenclatureGroup AND NOT Service

GRUPPE AV

Design av spørringsspråket 1C 8.2 som brukes til å gruppere resultatet.

For eksempel:

VELGE
Mottak av varer og tjenester varer,.
SUM(Receipt of GoodsServicesGoods.Quantity) AS Quantity,
SUM(Receipt of GoodsServicesGoods.Amount) AS Beløp
FRA
Dokumentmottak av varer og tjenester HVORDAN mottak av varer og tjenester

GRUPPE AV
Mottak av varer TjenesterGoods.Goods

Denne forespørselen vil oppsummere alle kvitteringer etter beløp og mengde etter vare.

Foruten nøkkelordet SUM Du kan bruke andre aggregerte funksjoner: MENGDE, ANTALL FORSKJELLIGE, MAKSIMUM, MINIMUM, GJENNOMSNITT.

HA

Et design som ofte glemmes, men det er veldig viktig og nyttig. Den lar deg spesifisere valg i form av en samlet funksjon, dette kan ikke gjøres i designet HVOR.

Eksempel på bruk av HAVING i en 1C-forespørsel:

VELGE
Mottak av varer og tjenester varer,.
SUM(Receipt of GoodsServicesGoods.Quantity) AS Quantity,
SUM(Receipt of GoodsServicesGoods.Amount) AS Beløp
FRA
Dokumentmottak av varer og tjenester HVORDAN mottak av varer og tjenester

GRUPPE AV
Mottak av varer og tjenester varer

SUM(Receipt of GoodsServicesGoods.Quantity) > 5

Så vi vil velge antall produkter som ankom mer enn 5 stykker.

BETYDNING()

For eksempel:

WHERE Bank = Verdi(Directory.Banks.EmptyLink)

WHERE Nomenclature Type = Verdi(Katalog.Nomenklaturtyper.Produkt)

WHERE Varetype = Verdi(Opptelling.Varetyper.Tjeneste)

TYPE på forespørsel

Datatypen kan kontrolleres ved å bruke funksjonene TYPE() og VALUETYPE() eller ved å bruke den logiske REFERENCE-operatoren.

UTTRYKKE()

Express-operatøren i 1C-spørringer brukes til å konvertere datatyper.

Syntaks: UTTRYKKE(<Выражение>HVORDAN<Тип значения>)

Ved å bruke den kan du konvertere strengverdier til dato eller referanseverdier til strengdata, og så videre.

I praktisk anvendelse Express()-operatoren brukes veldig ofte til å konvertere felt med ubegrenset lengde, fordi felt med ubegrenset lengde ikke kan velges, grupperes osv. Hvis slike felt ikke konverteres, vil du få en feilmelding Du kan ikke sammenligne felt med ubegrenset lengde og felt av inkompatible typer.

VELGE
ContactInformation.Object,
EXPRESS(ContactInfo.View AS ROW(150)) AS View
FRA
Register over informasjon Kontaktinformasjon HVORDAN kontaktinformasjon

GRUPPE AV
EXPRESS(ContactInfo.Representation AS ROW(150)),
ContactInformation.Object

ISNULL (ISNULL)

Ganske nyttig funksjon av 1C-spørringsspråket som sjekker verdien i posten, og om den er lik NULL, Dette lar deg erstatte det med din verdi. Oftest brukt når du skaffer virtuelle tabeller over saldoer og omsetning for å skjule NULL og sett en klar 0 (null).

ISNULL(Pre-month Taxes.AppliedFSS Benefit, 0)

En slik funksjon av 1C-spørringsspråket ISNULL vil returnere null hvis det ikke er noen verdi, noe som vil unngå en feil.

BLI MED

Det er 4 typer tilkoblinger: VENSTRE, IKKE SANT, KOMPLETT, INTERN.

VENSTRE og HØYRE FORBINDELSE

Sammenføyninger brukes til å koble to tabeller basert på en spesifikk tilstand. Innslag når VENSTRE BLI MED er at vi tar den første angitte tabellen i sin helhet og betinget binder den andre tabellen. Feltene i den andre tabellen som ikke kunne bindes av betingelse er fylt med verdien NULL.

Et eksempel på venstre sammenføyning i en 1C-forespørsel:

Den vil returnere hele tabellen og fylle ut "Bank"-feltet kun på de stedene der betingelsen "Motparter.Navn = Banker.Navn" er oppfylt. Dersom vilkåret ikke er oppfylt, settes Bank-feltet til NULL.

HØYRE JOIN i 1C 8.3 språk helt lik VENSTRE tilkobling, med unntak av én forskjell: i RETT TIL TILKOBLING"Hovedtabellen" er den andre, ikke den første.

FULL TILKOBLING

FULL TILKOBLING skiller seg fra venstre og høyre ved at den viser alle poster fra to tabeller og kobler kun sammen de som den kan koble til etter betingelse.

For eksempel:

FULL TILKOBLING
Directory.Banks HVORDAN Banker

AV

Spørringsspråket vil returnere begge tabellene fullstendig bare hvis vilkåret Join records er oppfylt. I motsetning til en venstre/høyre-kobling, er det mulig for NULL å vises i to felt.

INDRE BLI MED

INDRE BLI MED skiller seg fra full av emner, som viser bare de postene som kan kobles til i henhold til en gitt betingelse.

For eksempel:

FRA
Katalog Motparter AS Kunder

INDRE BLI MED
Directory.Banks HVORDAN Banker

AV
Clients.Name = Banks.Name

Denne spørringen vil kun returnere rader der banken og motparten har samme navn.

Konklusjon

Dette er bare en liten del av syntaksen fra 1C 8-spørringsspråket. I fremtiden vil jeg prøve å vurdere noen punkter mer detaljert, vise og mye mer!

NULL er ikke noe mer enn fravær av en verdi. Mange forveksler det med verdien "0" for typenummer, en tom referanse til et objekt eller en tom streng. På grunn av denne misforståelsen oppstår det mange feil.

NULL-verdien vises hvis forespørselen refererer til et ikke-eksisterende felt, egenskap eller ødelagt kobling.

Basert på SQL, som ikke tillater normal likhetstesting for NULL. Nedenfor er to måter å sjekke for NULL i 1C 8.3.

1C 8.3 spørringsspråkfunksjonen ISNULL() har to inngangsparametere:

uttrykk som skal testes;
erstatningsuttrykk.

Hvis verdien som testes er NULL, vil denne funksjonen returnere verdien til erstatningsuttrykket. Hvis verdien er en annen enn NULL, vil uttrykket som testes bli returnert.

Nedenfor er et eksempel. Den velger alle vareelementer i den tabellformede delen av produktet fra dokumentet "Mottak av varer og tjenester". Ved å bruke venstre sammenføyning tildeles hver vare siste pris fra informasjonsregisteret "Varepriser".

I dette tilfellet kan det oppstå en situasjon at det for en posisjon rett og slett ikke er en pris i registeret. I dette tilfellet vil ISNULL-funksjonen returnere oss den vanlige null. Hvis du ikke bruker det, vil vi motta en feilmelding når du prøver å utføre aritmetiske operasjoner på "Pris"-feltet med en NULL-verdi.

VELGE

ISNULL(Priser.Pris, 0) AS CurrentPrice
FRA

HVOR

DET ER NULL i SELECT-setningen

Ekvivalenten til ISNULL() er ISNULL, som brukes i SELECT-setningen og sjekker om verdien er NULL. "IS" i dette tilfellet antyder likhet, og spørringen i forrige eksempel vil se slik ut:

VELGE
Products.Nomenclature AS Produkt,
VALG
NÅR Prisene ER NULL
SÅ 0
ELLERS Priser.Pris
SLUTT SOM Gjeldende pris
FRA
Dokumentmottak av varer og tjenester AS
VENSTRE FORBINDELSE RegisterInformation.PricesNomenclature.SliceLast AS Priser
Programvareprodukter.Nomenklatur = Priser.Nomenklatur
HVOR
Products.Link = &LinkToDocument

Forskjeller mellom funksjonen ISNULL() og IS NULL

Som du kan se fra de foregående eksemplene, returnerer forespørselen i begge tilfeller de samme dataene. ISNULL()-funksjonen er en kortversjon av SELECTION WHEN... IS NULL...END, men den er fortsatt å foretrekke av følgende grunner:

ISNULL()-funksjonen optimaliserer spørringen. Den leses én gang, så når du sjekker et komplekst uttrykk, vil forespørselen behandles raskere.
ISNULL()-funksjonen forkorter konstruksjonen, noe som gjør spørringen mer lesbar.
Når du utfører funksjonen ISNULL() reduseres erstatningsuttrykket til typen av uttrykket som testes for strengtyper (til lengden på strengen) og numeriske typer (til bitdybden).

Spørringsspråket i 1C 8 er en forenklet analog av det velkjente "strukturerte programmeringsspråket" (som det oftere kalles, SQL). Men i 1C brukes den kun for å lese data en objektdatamodell brukes til å endre data.

En annen interessant forskjell er den russiske syntaksen. Selv om du faktisk kan bruke engelskspråklige konstruksjoner.

Eksempelforespørsel:

VELGE
Banks.Name,
Banker.Korrespondentkonto
FRA
Directory.Banks HVORDAN Banker

Denne forespørselen vil tillate oss å se informasjon om navn og korrespondentkonto til alle banker som finnes i databasen.

Spørrespråket er det enkleste og effektiv metode innhenting av informasjon. Som det fremgår av eksemplet ovenfor, må du bruke metadatanavn på spørringsspråket (dette er en liste over systemobjekter som utgjør konfigurasjonen, dvs. kataloger, dokumenter, registre osv.).

Beskrivelse av spørringsspråkkonstruksjoner

Spørringsstruktur

For å få data er det nok å bruke "SELECT" og "FROM" konstruksjonene. Den enkleste forespørselen ser slik ut:

VELG * FRA Kataloger.Nomenklatur

Der "*" betyr å velge alle feltene i tabellen, og Directories.Nomenclature – navnet på tabellen i databasen.

La oss se på et mer komplekst og generelt eksempel:

VELGE
<ИмяПоля1>HVORDAN<ПредставлениеПоля1>,
Sum(<ИмяПоля2>) HVORDAN<ПредставлениеПоля2>
FRA
<ИмяТаблицы1>HVORDAN<ПредставлениеТаблицы1>
<ТипСоединения>FORBINDELSE<ИмяТаблицы2>HVORDAN<ПредставлениеТаблицы2>
AV<УсловиеСоединениеТаблиц>

HVOR
<УсловиеОтбораДанных>

GRUPPE AV
<ИмяПоля1>

SORTER ETTER
<ИмяПоля1>

RESULTATER
<ИмяПоля2>
AV
<ИмяПоля1>

I denne forespørselen vi velger dataene til feltene "Feltnavn1" og "Feltnavn1" fra tabellene "Tabellnavn1" og "Tabellnavn", tildeler synonymer til feltene ved å bruke "HOW"-operatoren, og kobler dem ved å bruke en bestemt betingelse "Tabelltilkoblingsbetingelser".

Fra de mottatte dataene velger vi kun data som oppfyller betingelsen fra "HVOR" "Datavalgsbetingelse". Deretter grupperer vi forespørselen etter feltet "Feltnavn1", mens vi summerer "Feltnavn2". "Feltnavn1" og det siste feltet "Feltnavn2".

Det siste trinnet er å sortere forespørselen ved å bruke ORDER BY-konstruksjonen.

Generelle design

La oss se på de generelle strukturene til 1C 8.2 spørrespråk.

FØRSTn

Ved å bruke denne operatoren kan du få n antall første poster. Rekkefølgen på postene bestemmes av rekkefølgen i spørringen.

VELG FØRSTE 100
Banks.Name,
Banker Kode AS BIC
FRA
Directory.Banks HVORDAN Banker
SORTER ETTER
Banks.Name

Forespørselen vil motta de første 100 oppføringene i "Banker"-katalogen, sortert alfabetisk.

TILLATT

Dette designet er relevant for arbeid med mekanismen. Essensen av mekanismen er å begrense lesing (og andre handlinger) til brukere for spesifikke poster i en databasetabell, og ikke tabellen som helhet.

Hvis en bruker prøver å bruke en spørring til å lese poster som er utilgjengelige for ham, vil han motta en feilmelding. For å unngå dette bør du bruke "TILLATT"-konstruksjonen, det vil si at forespørselen bare vil lese postene som er tillatt for den.

VELG TILLATT
Lagring av tilleggsinformasjon
FRA
Directory.Repository av tilleggsinformasjon

DIVERSE

Ved å bruke "DIFFERENT" forhindrer du at dupliserte linjer kommer inn i 1C-søkeresultatet. Duplisering betyr at alle forespørselsfelt stemmer overens.

VELG FØRSTE 100
Banks.Name,
Banker Kode AS BIC
FRA
Directory.Banks HVORDAN Banker

Tom tabell

Denne konstruksjonen brukes svært sjelden til å kombinere spørringer. Når du blir med, må du kanskje spesifisere en tom nestet tabell i en av tabellene. "EmptyTable"-operatoren er akkurat riktig for dette.

Eksempel fra 1C 8 hjelp:

VELG Link.Number, TOM TABELL.(Nr., Vare, Antall) SOM sammensetning
FRA Dokument.Utgiftsfaktura
KOMBINER ALT
VELG Link.Number, Contents.(LineNumber, Product, Quantity)
FRA Document.Invoice Document.Invoice.Composition.*

ISNULL

En veldig nyttig funksjon som lar deg unngå mange feil. YesNULL() lar deg erstatte NULL-verdien med den ønskede. Svært ofte brukt for å sjekke for tilstedeværelsen av en verdi i sammenføyde tabeller, for eksempel:

VELGE
Nomenklatur Ref.
IsNULL(Item Remaining.QuantityRemaining,0) AS QuantityRemaining
FRA

Kan brukes på andre måter. For eksempel, hvis det for hver rad ikke er kjent i hvilken tabell verdien finnes:

ISNULL(InvoiceReceived.Dato, InvoiceIssued.Dato)

HOW er en operator som lar oss tildele et navn (synonym) til en tabell eller et felt. Vi så et eksempel på bruk ovenfor.

Disse konstruksjonene er veldig like - de lar deg få en strengrepresentasjon av ønsket verdi. Den eneste forskjellen er at REPRESENTATION konverterer alle verdier til en strengtype, mens REPRESENTATIONREF kun konverterer referanseverdier. REFERANSEREPRESENTASJON anbefales brukt i datasammensetningssystemspørringer for optimalisering, med mindre selvfølgelig referansedatafeltet er planlagt brukt i valg.

VELGE
View(Link), //string, for eksempel "Forhåndsrapport nr. 123 datert 10/10/2015
View(DeletionMark) AS DeleteMarkText, //string, "Ja" eller "Nei"
ViewReferences(DeletionMark) AS DeleteMarkBoolean //boolean, True or False
FRA
Document.Advance Report

UTTRYKKE

Express lar deg konvertere feltverdier til ønsket datatype. Du kan konvertere en verdi til enten en primitiv type eller en referansetype.

Express for en referansetype brukes til å begrense de forespurte datatypene i felt av en kompleks type, ofte brukt for å optimalisere systemytelsen. Eksempel:

EXPRESS(TabellCost.Subconto1 AS Directory.Cost Items).Type aktivitetForSkatteRegnskapskostnader

For primitive typer brukes denne funksjonen ofte for å begrense antall tegn i felt med ubegrenset lengde (slike felt kan ikke sammenlignes). For å unngå feilen " Ugyldige parametere i sammenligningsoperasjonen. Du kan ikke sammenligne felt
ubegrenset lengde og felt av inkompatible typer", må du uttrykke slike felt som følger:

EXPRESS(Comment AS Line(150))

FORSKJELL DATO

Få 267 videotimer på 1C gratis:

Et eksempel på bruk av IS NULL i en 1C-forespørsel:

VELGE FRA
Ref
VENSTRE TILKOBLING Registrer Akkumuleringer.Produkter I Varehus.Remaining AS Gjenværende produkt
ProgramvarenomenklaturRef.Link = Solgte varekomiteerRemains.Nomenclature
HVOR IKKE gjenværende produkter ER NULL

Datatypen i en spørring kan bestemmes ved å bruke funksjonene TYPE() og VALUETYPE() eller ved å bruke den logiske REFERENCE-operatoren. De to funksjonene er like.

Forhåndsdefinerte verdier

I tillegg til å bruke beståtte parametere i spørringer i 1C-spørringsspråket, kan du bruke forhåndsdefinerte verdier eller . For eksempel overføringer, forhåndsdefinerte kataloger, kontoplaner og så videre. For dette brukes "Value()"-konstruksjonen.

Brukseksempel:

WHERE Nomenclature.Type of Nomenclature = Verdi(Katalog.Types of Nomenclature.Produkt)

HVOR Motparter.Type kontaktinformasjon = Verdi(Opptelling.Typer kontaktinformasjon.Telefon)

HVOR Kontosaldo.Regnskapskonto = Verdi(Kontoplan.Profit.ProfittTap)

Tilkoblinger

Det er 4 typer tilkoblinger: VENSTRE, IKKE SANT, KOMPLETT, INTERN.

VENSTRE og HØYRE FORBINDELSE

For eksempel:

Den vil returnere hele tabellen over motparter og fylle ut "Bank"-feltet kun på de stedene hvor betingelsen "Motparter.Navn = Banker.Navn" vil være oppfylt. Dersom vilkåret ikke er oppfylt, settes Bank-feltet til NULL.

HØYRE JOIN på 1C-språk helt lik VENSTRE tilkobling, med unntak av én forskjell - i RETT TIL TILKOBLING"Hovedtabellen" er den andre, ikke den første.

FULL TILKOBLING

FULL TILKOBLING skiller seg fra venstre og høyre ved at den viser alle poster fra to tabeller og kobler kun sammen de som den kan koble til etter betingelse.

For eksempel:

FRA

FULL TILKOBLING
Directory.Banks HVORDAN Banker

AV

Spørringsspråket vil returnere begge tabellene fullstendig bare hvis betingelsen for å bli med i postene er oppfylt. I motsetning til en venstre/høyre-kobling, er det mulig for NULL å vises i to felt.

INDRE BLI MED

INDRE BLI MED skiller seg fra full ved at den viser bare de postene som kan kobles til i henhold til en gitt tilstand.

For eksempel:

FRA
Katalog Motparter AS Kunder

INDRE BLI MED
Directory.Banks HVORDAN Banker

AV
Clients.Name = Banks.Name

Denne spørringen vil kun returnere rader der banken og motparten har samme navn.

Foreninger

JOIN- og JOIN ALL-konstruksjonene kombinerer to resultater til ett. De. resultatet av å utføre to vil bli "slått sammen" til en felles.

Det vil si at systemet fungerer nøyaktig det samme som vanlige, bare for et midlertidig bord.

Hvordan bruke INDEX BY

Men ett punkt bør tas i betraktning. Å bygge en indeks på en midlertidig tabell tar også tid å fullføre. Derfor er det tilrådelig å bruke " "-konstruksjonen bare hvis det er sikkert kjent at det vil være mer enn 1-2 poster i den midlertidige tabellen. Ellers kan effekten være motsatt – ytelsen til indekserte felt kompenserer ikke for tiden det tar å bygge indeksen.

VELGE
Valutakurser Siste tverrsnitt Valuta AS Valuta,.
Valutakurser Siste tverrsnitt.
PUT Valutakurser
FRA
Informasjonsregister.Valutakurser.Siste Slice(&Periode,) AS ValutakursSiste Slice
INDEKSER ETTER
Valuta
;
VELGE
PriserNomenklatur.Nomenklatur,
PriserNomenklaturer.Pris,
PriserNomenklaturer.Valuta,
Valutakurser.Rate
FRA
Informasjonsregister.Nomenklaturpriser.Siste skive(&Periode,
Nomenklatur B (&Nomenklatur) OG PriceType = &PriceType) AS PriceNomenclature
VENSTRE JOIN Valutakurser AS Valutakurser
ProgramvarepriserNomenclatures.Currency = Valutakurser.Valuta

Gruppering

1C-spørringsspråket lar deg bruke spesielle aggregerte funksjoner når du grupperer søkeresultater. Gruppering kan også brukes uten aggregerte funksjoner for å "eliminere" duplikater.

Følgende funksjoner finnes:

Mengde, Mengde, Antall forskjellige, Maksimum, Minimum, Gjennomsnitt.

Eksempel #1:

VELGE
Salg av varer og tjenester, nomenklatur.
SUM(Sales of GoodsServicesGoods.Quantity) AS Quantity,
SUM(Salg of GoodsServicesGoods.Amount) AS Beløp
FRA

GRUPPE AV
Nomenklatur for varer og tjenester

Spørringen mottar alle linjer med varer og oppsummerer dem etter mengde og beløp etter vare.

Eksempel nr. 2

VELGE
Banks.Code,
ANTALL(DIFERENT Banks.Link) SOM antall duplikater
FRA
Directory.Banks HVORDAN Banker
GRUPPE AV
Banks.Code

Dette eksemplet vil vise en liste over BIC-er i "Banker"-katalogen og vise hvor mange duplikater som finnes for hver av dem.

Resultater

Resultater er en måte å hente data fra et system med hierarkisk struktur. Aggregerte funksjoner kan brukes til oppsummeringsfelt, akkurat som for grupperinger.

En av de mest populære måtene å bruke resultater på i praksis er batch-avskrivning av varer.

VELGE

FRA
Dokumenter Salg av varer og tjenester HVORDAN Salg av varer og tjenester
SORTER ETTER

RESULTATER
SUM(antall),
SUM(Sum)
AV
Nomenklatur

Resultatet av spørringen vil være følgende hierarkisk:

Generelle resultater

Hvis du trenger å få totaler for alle "totaler", bruk "GENERAL"-operatoren.

VELGE
Salg av varer og tjenester Varer Nomenclature AS Nomenclature,.
Salg av varer og tjenester varer Link AS Dokument,.
Salg av varer og tjenester varer Kvantitet AS Kvantitet,.
Salg av varer og tjenester varer. Beløp
FRA
Dokumenter Salg av varer og tjenester HVORDAN Salg av varer og tjenester
SORTER ETTER
Salg av varer og tjenester
RESULTATER
SUM(antall),
SUM(Sum)
AV
ER VANLIG,
Nomenklatur

Som et resultat av å utføre forespørselen får vi følgende resultat:

I hvilket 1 grupperingsnivå er aggregeringen av alle nødvendige felt.

Arrangere

Operatoren ORDER BY brukes til å sortere resultatet av en spørring.

Sortering for primitive typer (streng, tall, boolsk) skjer etter vanlige regler. For felt med referansetyper skjer sortering i henhold til den interne representasjonen av referansen ( unik identifikator), og ikke med kode eller lenkepresentasjon.

VELGE

FRA
Directory.Nomenclature AS Nomenclature
SORTER ETTER
Navn

Forespørselen vil vise en liste over navn i nomenklaturkatalogen, sortert alfabetisk.

Autobestilling

Resultatet av en spørring uten sortering er et kaotisk presentert sett med rader. Utviklerne av 1C-plattformen garanterer ikke at rader sendes ut i samme sekvens når de utfører de samme spørringene.

Hvis du trenger å vise tabellposter i konstant rekkefølge, må du bruke Auto-Order-konstruksjonen.

VELGE
Nomenclature.Name AS Navn
FRA
Directory.Nomenclature AS Nomenclature
AUTO BESTILLING

Virtuelle bord

Virtuelle tabeller i 1C er unik funksjon 1C spørringsspråk, som ikke finnes i andre lignende syntakser. Virtuelt bord – rask måte innhenting av profilinformasjon fra registre.

Hver registertype har sitt eget sett med virtuelle tabeller, som kan variere avhengig av registerinnstillingene.

kutt av den første;
kutt av sistnevnte.

rester;
revolusjoner;
saldo og omsetning.

bevegelser fra subconto;
revolusjoner;
hastighet Dt Kt;
rester;
saldo og omsetning
subconto.

utgangspunkt;
grafiske data;
faktisk gyldighetsperiode.

For løsningsutvikleren er dataene hentet fra én (virtuell) tabell, men faktisk tar 1C-plattformen dem fra mange tabeller og transformerer dem til den nødvendige formen.

VELGE
Produkter i varehusrester og omsetning.
ProductsIn WarehousesRemainingAndTurnover.QuantityInitialRemaining,
ProductsInWarehousesRemainsAndTurnover.QuantityOmsetning,
GoodsIn WarehousesRemainsAndTurnover.QuantityIncoming,
ProdukterI varehusRemainsAndTurnover.QuantityConsumption,
ProductsI WarehousesRemainingsAndTurnover.QuantityFinalRemaining
FRA
RegisterAccumulations.GoodsInWarehouses.RemainsAndTurnover AS GoodsInWarehousesRemainsAndTurnover

Denne forespørselen lar deg raskt få et stort nummer av data.

Virtuelle bordalternativer

Et veldig viktig aspekt ved å jobbe med virtuelle tabeller er bruken av parametere. Virtuelle tabellparametere er spesialiserte parametere for valg og konfigurasjon.

For slike tabeller anses det som feil å bruke utvalg i "HVOR"-konstruksjonen. I tillegg til at spørringen blir suboptimal, er det mulig å motta feil data.

Et eksempel på bruk av disse parameterne:

Register over varer i varehus og omsetning (& Begynnelse av perioden, & Slutt av perioden, Måned, Bevegelser og grenser for perioden, Nomenklatur = & Nødvendig nomenklatur).

Algoritme for virtuelle tabeller

For eksempel lagrer det mest brukte virtuelle bordet av typen "Remains" data fra to fysiske tabeller - balanser og bevegelser.

Når du bruker en virtuell tabell, utfører systemet følgende manipulasjoner:

Vi får den nærmeste beregnede verdien når det gjelder dato og mål i totaltabellen.
Vi "legger til" beløpet fra bevegelsestabellen til beløpet fra totaltabellen.

Slike enkle handlinger kan forbedre ytelsen til systemet som helhet betydelig.

Bruke spørringsbyggeren

Spørringsbygger– et verktøy innebygd i 1C Enterprise-systemet som i stor grad letter utviklingen av databasespørringer.

Spørringsbyggeren har et ganske enkelt, intuitivt grensesnitt. La oss likevel se på bruken av spørringskonstruktøren mer detaljert.

Spørringstekstkonstruktøren startes fra kontekstmenyen (høyre museknapp) på ønsket sted i programkoden.

Beskrivelse av 1C-forespørselskonstruktøren

La oss se på hver kategori av designeren mer detaljert. Unntaket er Builder-fanen, som er et emne for en annen diskusjon.

Kategorien Tabeller og felt

Denne kategorien spesifiserer datakilden og feltene som må vises i rapporten. I hovedsak er konstruksjonene SELECT.. FROM beskrevet her.

Kilden kan være en fysisk databasetabell, en virtuell registertabell, midlertidige tabeller, nestede spørringer, etc.

I kontekstmenyen til virtuelle tabeller kan du angi parametere for virtuelle tabeller:

Fanen Tilkoblinger

Fanen brukes til å beskrive sammenhenger av flere tabeller og lager konstruksjoner med ordet TILKOBLING.

Kategorien Gruppering

På denne fanen lar systemet deg gruppere og oppsummere de nødvendige feltene i tabellresultatet. Beskriver bruken av konstruksjonene GRUPPER ETTER, SUM, MINIMUM, GJENNOMSNITT, MAKSIMUM, ANTALL, ANTALL FORSKJELLIGE.

Betingelser-fanen

Ansvarlig for alt som kommer i forespørselsteksten etter WHERE-konstruksjonen, dvs. for alle betingelsene som stilles til de mottatte dataene.

Avansert-fanen

Tab I tillegg fylt med alle slags parametere som er veldig viktige. La oss se på hver av egenskapene.

Gruppering Valg av poster:

Første n– en parameter som returnerer bare N poster til spørringen (den FØRSTE operatøren)
Ingen duplikater– sikrer unikheten til de mottatte postene (ANNET operatør)
Tillatt– lar deg velge bare de postene som systemet lar deg velge under hensyntagen til (TILLATT konstruksjon)

Gruppering Forespørselstype bestemmer hvilken type forespørsel som vil være: datainnhenting, opprettelse av en midlertidig tabell eller ødeleggelse av en midlertidig tabell.

Under er det et flagg Lås mottatte data for senere endring. Den lar deg aktivere muligheten til å stille inn datalåsing, som sikrer sikkerheten til data fra det øyeblikket de leses til de endres (relevant kun for Automatisk modus forriglinger, design FOR ENDRING).

Sammenføyninger/aliaser-fanen

På denne kategorien av spørringsdesigneren kan du angi muligheten til å slå sammen forskjellige tabeller og aliaser (HOW-konstruksjonen). Tabellene er angitt på venstre side. Hvis du setter flaggene på motsatt side av tabellen, vil UNITE-konstruksjonen bli brukt, ellers - UNITE ALL (forskjeller mellom de to metodene). På høyre side er korrespondansen til feltene i forskjellige tabeller indikert hvis korrespondansen ikke er spesifisert, vil spørringen returnere NULL.

Bestill-fanen

Dette spesifiserer rekkefølgen som verdiene er sortert i (ORDER BY) - synkende (DESC) eller stigende (ASC).

Det er også et interessant flagg - Autobestilling(i forespørselen - AUTO BESTILLING). Som standard viser 1C-systemet data i en "kaotisk" rekkefølge. Hvis du setter dette flagget, vil systemet sortere data etter interne data.

Søk Batch-fanen

På fanen spørringsdesigner kan du opprette nye og også bruke den som navigasjon. I forespørselsteksten er pakker atskilt med symbolet ";" (komma).

"Query"-knappen i spørringsdesigneren

I nedre venstre hjørne av forespørselsdesigneren er det en forespørsel-knapp, som du kan se forespørselsteksten med når som helst:

I dette vinduet kan du gjøre justeringer av forespørselen og utføre den.

Bruke spørringskonsollen

Query Console er enkel og praktisk måte for feilsøking av komplekse søk og rask innhenting av informasjon. I denne artikkelen vil jeg prøve å beskrive hvordan du bruker Query Console og gi en lenke for å laste ned Query Console.

La oss se nærmere på dette verktøyet.

Last ned 1C spørrekonsoll

Først av alt, for å begynne å jobbe med spørringskonsollen, må du laste den ned fra et sted. Behandlinger er vanligvis delt inn i to typer - kontrollerte former og konvensjonelle (eller noen ganger kalles de 8.1 og 8.2/8.3).

Jeg prøvde å kombinere disse to typene i en prosessering - i ønsket driftsmodus åpnes den nødvendig skjema(i administrert modus fungerer konsollen bare i tykk modus).

Beskrivelse av 1C-spørringskonsollen

La oss begynne å se på spørringskonsollen med en beskrivelse av hovedbehandlingspanelet:

I spørringskonsollens overskrift kan du se utførelsestiden for den siste spørringen med millisekunders nøyaktighet, dette lar deg sammenligne ulike design når det gjelder ytelse.

Den første gruppen med knapper i kommandolinjen er ansvarlig for å lagre gjeldende spørringer til en ekstern fil. Dette er veldig praktisk; du kan alltid gå tilbake til å skrive en kompleks forespørsel. Eller, for eksempel, lagre en liste over typiske eksempler på visse design.

Til venstre, i «Request»-feltet, kan du opprette nye forespørsler og lagre dem i en trestruktur. Den andre gruppen av knapper er ansvarlig for å administrere listen over forespørsler. Ved å bruke den kan du opprette, kopiere, slette, flytte en forespørsel.

Henrettebe om– enkel utførelse og resultater
Utfør pakken– lar deg se alle mellomliggende spørringer i en gruppe spørringer
Viser midlertidige tabeller– lar deg se resultatene som midlertidige spørringer returnerer på en tabell

Forespørselsparametere:

Lar deg angi gjeldende parametere for forespørselen.

I vinduet med spørringsparametere er følgende interessant:

Knapp Få fra forespørsel finner automatisk alle parametere i forespørselen for utviklerens bekvemmelighet.
Flagg Felles parametere for alle forespørsler– når den er installert, sletter ikke behandlingen parametrene når du går fra forespørsel til forespørsel i den generelle listen over forespørsler.

Angi en parameter med en liste over verdier Det er veldig enkelt, bare når du velger en parameterverdi, klikker du på fjernverdiknappen (kryss), systemet vil be deg om å velge datatypen, der du må velge "Verdiliste":

I topppanelet er det også en knapp for å hente innstillingene for spørrekonsollen:

Her kan du spesifisere parametere for automatisk lagring av spørringer og parametere for utføring av spørringer.

Forespørselsteksten legges inn i konsollforespørselsfeltet. Dette kan gjøres ved ganske enkelt å skrive en spørringstest eller ringe spesialverktøy– spørringsdesigner.

1C 8-forespørselskonstruktøren kalles fra kontekstmenyen(høyre museknapp) når du klikker på inntastingsfeltet:

Også i denne menyen er det slike nyttige funksjoner som å slette eller legge til linjeskift ("|") til forespørselen, eller å motta forespørselskoden i denne praktiske formen:

Request = Ny forespørsel;
Request.Text = ”
|VELG
| Valutaer.Link
|FRA
| Directory.Currencies AS Valutaer”;
RequestResult = Request.Execute();

Det nedre feltet i spørringskonsollen viser søkeresultatfeltet, og det er grunnen til at denne behandlingen ble opprettet:

I tillegg kan spørringskonsollen, i tillegg til listen, vise data i form av et tre - for spørringer som inneholder totaler.

Spørringsoptimalisering

Et av de viktigste punktene for å øke produktiviteten til 1C enterprise 8.3 er optimaliseringforespørsler. Dette punktet er også veldig viktig når bestått sertifiseringen. Nedenfor vil vi snakke om typiske årsaker til ikke-optimal spørringsytelse og optimaliseringsmetoder.

Valg i en virtuell tabell ved hjelp av WHERE-konstruksjonen

Det er nødvendig å bruke filtre på de virtuelle tabelldetaljene bare gjennom VT-parametrene. Under ingen omstendigheter bør du bruke WHERE-konstruksjonen for valg i en virtuell tabell. Dette er en alvorlig feil fra et optimaliseringssynspunkt. Ved valg med WHERE vil systemet faktisk motta ALLE poster og først da velge de nødvendige.

IKKE SANT:

VELGE

FRA
Register over gjensidige oppgjør med deltakere i organisasjoner.
,
Organisasjon = &Organisasjon
OG Individuell = &Individuell) HVORDAN Gjensidige oppgjør med deltakere i organisasjoner balanserer

FEIL:

VELGE
Gjensidige oppgjør med deltakere i organisasjoner Beløpssaldo
FRA
Register over akkumuleringer med deltakere i organisasjoner (,) HVORDAN Gjensidige oppgjør med deltakere i organisasjoner
HVOR
Gjensidige oppgjør med deltakere av organisasjoner Saldo = & Organisasjon
OG Gjensidige oppgjør med deltakere i organisasjoner Individuelle = &Individuelle

Hente verdien av et felt av en kompleks type ved å bruke en prikk

Når du mottar data av en kompleks type i en spørring gjennom en prikk, kobles systemet sammen med en venstre sammenføyning nøyaktig så mange tabeller som det er mulige typer i feltet for den komplekse typen.

For eksempel er det høyst uønsket for optimalisering for å få tilgang til registerpostfeltet – registrar. Registraren har en sammensatt datatype, blant annet er alle mulige dokumenttyper som kan skrive data til registeret.

FEIL:

VELGE
Record Set.Recorder.Date,
RecordSet.Quantity
FRA
RegisterAccumulations.ProductsOrganizations AS Set of Records

Det vil si, faktisk vil en slik spørring ikke få tilgang til én tabell, men 22 databasetabeller (dette registeret har 21 registrartyper).

IKKE SANT:

VELGE
VALG
NÅR ProductsOrg.Registrar LINK Document.Salg of Products and Services
SÅ EXPRESS(ProductsOrganization.Registrar AS Document.Sales of GoodsServices).Dato
NÅR GoodsOrg.Registrar LINK Document.Receipt of GoodsServices
SÅ EXPRESS(GoodsOrg.Registrar AS Document.Receipt of GoodsServices).Dato
SLUTT SOM DATO,
ProductsOrg.Quantity
FRA
Registrer Akkumuleringer.ProdukterOrganisasjoner AS ProdukterOrganisasjon

Eller det andre alternativet er å legge til slik informasjon i detaljene, for eksempel i vårt tilfelle å legge til en dato.

IKKE SANT:

VELGE
ProdukterOrganisasjoner.Dato,
ProdukterOrganisasjoner.Antall
FRA
Register of Goods of Organizations AS Goods of Organizations

Undersøk i en sammenføyningstilstand

For optimalisering er det uakseptabelt å bruke underspørringer i sammenføyningsforhold, dette bremser søket betydelig. Det er tilrådelig å bruke VT i slike tilfeller. For å koble til, må du bare bruke metadata og VT-objekter, etter å ha indeksert dem tidligere etter tilkoblingsfelt.

FEIL:

VELG …

VENSTRE BLI MED (
VELG FRA RegisterInformation.Limits
HVOR …
GRUPPE AV...
) AV …

IKKE SANT:

VELG …
PUT-grenser
FRA Informasjonsregister.Begrensninger
HVOR …
GRUPPE AV...
INDEKSER ETTER...;

VELG …
FROM Dokument salg av varer og tjenester
LEFT JOIN Grenser
AV …;

Bli med poster med virtuelle tabeller

Det er situasjoner når systemet ikke fungerer optimalt når du kobler et virtuelt bord til andre. I dette tilfellet, for å optimere ytelsen til spørringen, kan du prøve å plassere den virtuelle tabellen i en midlertidig, og ikke glemme å indeksere de sammenføyde feltene i den midlertidige tabellspørringen. Dette skyldes at VT-er ofte finnes i flere fysiske bord DBMS, som et resultat, kompileres en underspørring for å velge dem, og problemet viser seg å være lik det forrige punktet.

Bruke valg basert på ikke-indekserte felt

En av de vanligste feilene når du skriver spørringer er å bruke betingelser på ikke-indekserte felt, dette motsier spørringsoptimaliseringsregler. DBMS kan ikke utføre en spørring optimalt hvis spørringen inkluderer valg på ikke-indekserbare felt. Hvis du tar en midlertidig tabell, må du også indeksere tilkoblingsfeltene.

Det må være en passende indeks for hver tilstand. En passende indeks er en som tilfredsstiller følgende krav:

Indeksen inneholder alle feltene som er oppført i betingelsen.
Disse feltene er helt i begynnelsen av indeksen.
Disse valgene er fortløpende, det vil si at verdier som ikke er involvert i spørringsbetingelsen, ikke "kiles" mellom dem.

Hvis DBMS ikke velger de riktige indeksene, vil hele tabellen bli skannet - dette vil ha en svært negativ innvirkning på ytelsen og kan føre til forlenget blokkering av hele settet med poster.

Bruker logisk ELLER under forhold

Det er alt, denne artikkelen dekket de grunnleggende aspektene ved spørringsoptimalisering som enhver 1C-ekspert bør vite.

Et veldig nyttig gratis videokurs om søkeutvikling og optimalisering, Jeg anbefaler på det sterkeste for nybegynnere og mer!

Be om . Tekst = "VELGE | StorageUnits.Link |FRA | Directory.usStorageUnits HVORDAN du brukerStorageUnits // Eksempel 1: sammenligning med en tom boolsk verdi: |HVOR | StorageUnits.AllowSelectionFromReserveZone = False // Eksempel 2. men hvis denne boolsk er definert, er den bedre slik: // betingelse for en negativ boolsk: |HVOR | IKKE lagringsenheter Tillat valg fra reservesone // Eksempel 3. valg basert på tilstanden til et tomt felt som har typen "katalog av en bestemt type" |HVOR | StorageUnits.ActiveSelectionArea = VERDI(Directory.SelectionArea.EmptyLink) // Eksempel 3a. valg basert på tilstanden til et tomt felt med typen "dokument av en bestemt type" |HVOR | OurInformationRegister.Document = VERDI(Document.OurDocument.EmptyLink) // Eksempel 3b. valg basert på tilstanden til et tomt felt av typen "dokumenter" forskjellige typer" (sammensatt felt) |HVOR | (OurInformationRegister.Document = VALUE(Document.OurDocument1.EmptyLink) | OR OurInformationRegister.Document = VALUE(Document.OurDocument2.EmptyLink) | ELLER... (osv. - vi viser sekvensielt betingelsene for alle mulige typer av dette sammensatte feltet) ) // Eksempel 4. eller omvendt, hvis du trenger å velge en utfylt verdi av typen "streng", vil betingelsen hjelpe: |HVOR | Lagringsenhet.navn > """" // Eksempel 5. Hvis du trenger å velge dokumenter av en bestemt type, med en sammensatt datatype, for eksempel i "RunningTasks"-registeret, har "Task"-ressursen en sammensatt type, blant verdiene som dokumentet "Utvalg" er mulig |HVOR | EXPRESS(InformasjonsregisterUtførte oppgaver.Task AS Document.Selection) LINK Document.Selection // Eksempel 5a. Et annet lignende eksempel når du trenger å velge dokumenter av en bestemt type | VALG | NÅR DU SKAL UTTRYKKES (ag Korrespondanse av dokumenter. DocumentBU AS Dokument. Mottak av varer og tjenester) LINK Dokumenter for mottak av varer og tjenester | SÅ ""Mottak av varer og tjenester"" | NÅR DU UTRYKKES (ag Korrespondanse av dokumenter. DocumentBU AS Dokument. Salg av varer og tjenester) LINK Dokument salg av varer og tjenester | SÅ ""Salg av varer og tjenester"" | ELLER """" | AVSLUTT SOM dokumentvisning // Eksempel 6. valg etter betingelse av en udefinert verdi: |HVOR | SavedSettings.User = UDEFINERT // Eksempel 7. valg etter type bevegelse "Innkommende" av akkumuleringsregisteret, "Utgift" - tilsvarende): |HVOR | RegProductsInRetail.MovementType = VERDI(MovementTypeAccumulation.Incoming) // Eksempel 8. Hvordan indikere i en forespørsel at det ikke er nødvendig å utføre forespørselen (for eksempel må du, avhengig av en eller annen tilstand, programmessig returnere et tomt forespørselsresultat - Request.Text = StrReplace(Request.Text, "WHERE Doc.Link = &DocumentLink" , "HVOR ER LØGNEN");). For å gjøre dette, legg bare til betingelsen "Where is False". Forresten, uavhengig av mengden av data som er forespurt i prøven, vil en slik forespørsel bli utført umiddelbart. |HVOR ER LØGNEN // Eksempel 9. Kontroller at søkeresultatet inneholder data: Hvis ikkeBe om.Henrette().Tømme() Deretter // Eksempel 10. utvalg basert på en tom dato: |HVOR | tbStrings.CancellationDate = DATOTIME(1, 1, 1)

Jeg bestemte meg for å gi mitt bidrag og beskrive de funksjonene ved språket som ikke ble diskutert i artiklene ovenfor. Artikkelen er rettet mot nybegynnere.

1. "IZ" design.

For å hente data fra databasen er det slett ikke nødvendig å bruke "FROM"-konstruksjonen.
Eksempel: Vi må velge all informasjon om banker fra bankkatalogen.
Be om:

SELECT Directory.Banks.*

Velger alle felt fra bankkatalogen. Og ligner på forespørselen:

VELG Banker.* FRA Directory.Banks AS Banker

2. Bestilling av data etter referansefelt

Når vi trenger å organisere spørringsdata etter primitive typer: "String", "Number", "Date", etc., så løses alt ved å bruke "ORDER BY"-konstruksjonen hvis du trenger å bestille dataene etter et referansefelt? Referansefeltet er en lenke, en unik identifikator, dvs. Grovt sett kan et vilkårlig sett med tegn og vanlig rekkefølge gi et resultat som ikke er helt forventet. For å bestille referansefelt brukes konstruksjonen "AUTO BESTILLING". For å gjøre dette må du først bestille dataene direkte etter referansetypen ved å bruke "ORDER BY"-konstruksjonen, og deretter "AUTO ORDER"-konstruksjonen.

I dette tilfellet, for dokumenter, vil bestillingen skje i rekkefølgen "Dato->Nummer", for oppslagsverk i "Hovedvisning". Hvis bestillingen ikke skjer etter referansefelt, anbefales det ikke å bruke konstruksjonen "AUTO BESTILLING".

I noen tilfeller kan "AUTO BESTILLING"-konstruksjonen bremse utvelgelsesprosessen. På samme måte kan du skrive om uten automatisk bestilling av dokumenter:

3.Få en tekstrepresentasjon av en referansetype. "PRESENTASJON" design.

Når du trenger å vise et felt av en referansetype, for eksempel "Bank"-feltet, som er en lenke til et element i "Banks"-katalogen, må du forstå at når du viser dette feltet, vil en underspørring til " Banks"-katalogen vil automatisk bli utført for å få en visning av katalogen. Dette vil redusere datautgangen. For å unngå dette, må du bruke "PREPRESENTATION"-konstruksjonen i forespørselen for umiddelbart å få en representasjon av objektet og deretter vise det for visning.

I datasammensetningssystemet brukes denne mekanismen som standard, men når du lager oppsett i celler, bør du spesifisere representasjonen av referansefeltet, og for eksempel plassere selve lenken i transkripsjonen.

4. Betingelse for prøvetaking av data etter mal.

For eksempel må du få Mobil ansatte av typen (8 -123- 456-78-912). For å gjøre dette må du angi følgende betingelse i forespørselen:

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

Tegnet "_" er et tjenestetegn og erstatter et hvilket som helst tegn.

5. Samtidig bruk av totaler og grupperinger.

Totaler brukes ofte sammen med grupperinger, i dette tilfellet kan det hende at aggregerte funksjoner ikke er spesifisert i totalene.

SELECT Provision of Services.Organization AS Organization, Provision of Services.Nomenclature AS Nomenclature, SUM(Provision of Services.Amount of Document) AS Sum of Document FROM Document.Provision of Services AS Provision of Services GROUP BY Provision of Services.Organisation, Provision of Services.Nomenklatur RESULTATER AV GENERELT, Organisasjon, nomenklatura

I dette tilfellet vil spørringen returnere nesten det samme som følgende spørring:

SELECT Provision of Services.Organization AS Organisation, Provision of Services.Nomenclature AS Nomenclature, Provision of Services.Amount of Document AS Amount of Document FROM Document.Provision of Services AS Provision of Services RESULTATE AMOUNT (Amount of Document) BY GENERAL, Organisation, Nomenklatur

Bare den første spørringen vil skjule poster med samme nomenklatur.

6. Frareferansefelt.

Å referere til felt gjennom en prikk kallesen. For eksempel Betaling.Organisasjon.Administrativ enhet. I dette tilfellet, i referansefeltet "Organisasjon" i "Betaling"-dokumentet, refererer det til en annen tabell "Organisasjoner", der verdien av attributtet "Administrativ enhet" vil bli oppnådd. Det er viktig å forstå at når du får tilgang til felt gjennom en prikk, oppretter plattformen implisitt en underspørring og kobler sammen disse tabellene.

Be om:

Kan representeres som:

VELG Payment.Link, Payment.Organization, Payment.Organization, Organisations. AdministrativeUnit FROM Document.Payment AS Payment LEFT JOIN Directory.Organizations AS Software Organizations Payment.Organization = Organizations.Link

Når du refererer til referansefelt av en sammensatt type, forsøker rammeverket å lage implisitte sammenføyninger til alle tabeller som er en del av feltets type. I dette tilfellet vil ikke spørringen være optimal Hvis det er klart kjent hvilken type felt det er, er det nødvendig å begrense slike felt etter type med en konstruksjon UTTRYKKE().

For eksempel er det et akkumuleringsregister "Ufordelte betalinger", der flere dokumenter kan fungere som registrar. I dette tilfellet er det feil å innhente verdiene til registrardetaljene på denne måten:

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

du bør begrense typen av det sammensatte feltet til logger:

VELG EXPRESS(UnallocatedPayments.Register AS Document.Payment).Dato, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

7. Konstruksjon "HVOR"

Med en venstre sammenføyning av to tabeller, når du pålegger en "WHERE"-betingelse på den høyre tabellen, vil vi få et resultat som ligner resultatet med en indre sammenføyning av tabeller.

Eksempel. Det er nødvendig å velge alle klienter fra klientkatalogen og for de klienter som har et betalingsdokument med verdien av attributtet "Organisasjon" = &Organisasjon, vis dokumentet "Betaling", for de som ikke har det, ikke vis det.

Resultatet av spørringen vil returnere poster bare for de klientene som hadde betaling etter organisasjon i parameteren, og vil filtrere ut andre klienter. Derfor må du først motta alle betalinger for "slik og slik" organisasjon i en midlertidig tabell, og deretter koble den til "Kunder"-katalogen ved å bruke en venstre sammenføyning.

VELG Payment.Link AS Payment, Payment.Shareholder AS Client PLASS toPayments FROM Document.Payment AS Payment WHERE Payment.Branch = &Branch; ////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(tPayment.Payment, "") AS Betaling FRA Directory .Clients AS Klienter VENSTRE FORBINDELSE topayments SOM topayments SOFTWARE Clients.Link = topayments.Client

Du kan komme deg rundt denne tilstanden på en annen måte. Det er nødvendig å pålegge en "WHERE"-betingelse direkte på forholdet mellom de to tabellene. Eksempel:

VELG Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers VENSTRE CONNECTION Document.Payment AS Payment Software (Clients.Link = Payment.Client AND Payment.Client.Name LIKE "Sugar Packet") GRUPPE ETTER Clients.Link, Payment. Link

8. Blir med nestede og virtuelle tabeller

Nestede søk ofte nødvendig for å hente data basert på en eller annen tilstand. Hvis du deretter bruker dem sammen med andre tabeller, kan dette redusere utførelsen av spørringen kritisk.

For eksempel må vi få saldobeløpet per gjeldende dato for noen klienter.

SELECT UnallocatedPaymentsBalances.Customer, UnallocatedPaymentsBalances.AmountBalance FROM (SELECT Clients.Link AS Link FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Clients)) AS NestedQuery LEFT JOIN RegisterAccumulations.UnallocatedPayments.UnallocatedPayments lokalisertPaymentsBalances. Kunde

Når du utfører en slik spørring, kan DBMS-optimalisatoren gjøre feil når du velger en plan, noe som vil føre til suboptimal utførelse av spørringen. Når du kobler sammen to tabeller, velger DBMS-optimalisatoren en tabellsammenføyningsalgoritme basert på antall poster i begge tabellene. Hvis det er en nestet spørring, er det ekstremt vanskelig å bestemme antall poster som den nestede spørringen vil returnere. Derfor bør du alltid bruke midlertidige tabeller i stedet for nestede spørringer. Så la oss omskrive forespørselen.

SELECT Clients.Link AS Link PLASS tClients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&Clients) ; ////////////////////////////////////////////// //////////////////////////////////// VELG tClients.Link, UnallocatedPaymentsRemains.AmountRemaining, FROM tClients AS tClients LEFT JOIN RegisterAccuulations.UnallocatedPayments.Balances (, Client) IN (SELECT tClients. Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

I dette tilfellet vil optimizeren kunne bestemme hvor mange poster den midlertidige tabellen tClients bruker og vil kunne velge den optimale algoritmen for å slå sammen tabeller.

Virtuelle bord , lar deg få praktisk talt ferdige data for de fleste brukte oppgaver (Slice of the First, Slice of the Last, Remains, Turnovers, Remains og Turnovers). Nøkkelord her er virtuelle. Disse tabellene er ikke fysiske, men kompileres av systemet på farten, dvs. Ved mottak av data fra virtuelle tabeller samler systemet inn data fra de endelige registertabellene, komponerer, grupperer og sender det ut til brukeren.

De. Når du kobler til en virtuell tabell, opprettes en tilkobling til en underspørring. I dette tilfellet kan DBMS-optimalisatoren også velge en ikke-optimal tilkoblingsplan. Hvis spørringen ikke genereres raskt nok og spørringen bruker sammenføyninger i virtuelle tabeller, anbefales det å flytte tilgangen til de virtuelle tabellene til en midlertidig tabell, og deretter lage en sammenføyning mellom to midlertidige tabeller. La oss omskrive den forrige forespørselen.

VELG Clients.Link AS Link PLASSER tClients FROM Directory.Clients AS Clients INDEKS BY Link HVOR
Clients.Link B (&Clients) ; ////////////////////////////////////////////// ///////////////////////////// SELECT ULLOCATEDPAYMENTS.AmountBalance, UnfordoatedPayments.Client as Client Place Balances from RegisterAccumulations.unallocatedPayments.Balances (, klient B ( SELECT tClients Link FROM tClients)) AS UnallocatedPaymentsBalances; ////////////////////////////////////////////// ////////////////////////// SELECT tClients.Link, toRemainders.AmountRemaining AS AmountRemaining FROM tClients AS tClients LEFT JOIN toRemainders AS Remainders BY tClients.Link = tRemainings.Client

9.Sjekker resultatet av forespørselen.

Resultatet av spørringen kan være tomt for å se etter tomme verdier, bruk følgende konstruksjon:

ResRequest = Request.Execute(); Hvis resQuery.Empty() Returner deretter; slutt om;

Metode Tømme() bør brukes før metoder Velge() eller Lesse(), siden det tar tid å hente samlingen.

Det er ikke en åpenbaring for noen at det er ekstremt uønsket å bruke spørringer i en loop. Dette kan kritisk påvirke driftstiden til en bestemt funksjon. Det er svært ønskelig å motta alle dataene i forespørselen og deretter behandle dataene i en loop. Men noen ganger er det tilfeller der det blir umulig å flytte forespørselen utenfor loopen. I dette tilfellet, for optimalisering, kan du flytte opprettelsen av spørringen utenfor loopen, og i loopen erstatte de nødvendige parameterne og utføre spørringen.

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

Dette vil spare systemet fra syntakskontroll av forespørselen i en løkke.

11. Konstruksjon "HAVING".

VELG Betaling.Kunde, BELØP(Betaling.Beløp) SOM Beløp FRA Dokument.Betaling SOM Betaling HVOR MÅNED(Betalingsdato) = 9 GRUPPER ETTER Betaling.Kunde HAR BELØP(Betal.Beløp) > 13000

I konstruktøren, for å gjøre dette, går du bare til fanen "Betingelser", legg til en ny tilstand og merker av for "Egendefinert". Så er det bare å skrive Beløp (Betaling.Beløp) > 13000

12. NULL-verdi

Jeg vil ikke her beskrive prinsippene for treverdi-logikk i databasen, det er mange artikler om dette emnet. Bare kort om hvordan NULL kan påvirke resultatet av spørringen. Verdien NULL er egentlig ikke en verdi, og det faktum at verdien er udefinert er ukjent. Derfor returnerer enhver operasjon med NULL NULL, enten det er addisjon, subtraksjon, divisjon eller sammenligning. En NULL-verdi kan ikke sammenlignes med en NULL-verdi fordi vi ikke vet hva vi skal sammenligne. De. begge disse sammenligningene er: NULL = NULL, NULL<>NULL er ikke sant eller usant, det er ukjent.

La oss se på et eksempel.

For de kundene som ikke har betalinger, må vi vise "Sign"-feltet med verdien "Ingen betalinger". Dessuten vet vi med sikkerhet at vi har slike kunder. Og for å gjenspeile essensen av det jeg skrev ovenfor, la oss gjøre det på denne måten.

VELG "Ingen betalinger" AS Attribut, NULL AS Document PLACE topbetalinger; ////////////////////////////////////////////// //////////////////////////// select clients.link as client, betaling.link hvordan betaling setter tclientpayment fra katalog.clients som klienter forlot tilkoblingsdokumentet. Payment AS Payment Software Clients.Link = Payment.Shareholder; ////////////////////////////////////////////// //////////////////////////// select tclientpayment.client from tclientpayment as tclientpayment internt join tpayment as ttopay by tclientpayment.payment = tpayment

Vær oppmerksom på den andre midlertidige tabellen tClientPayment. Med venstre join velger jeg alle klienter og alle betalinger for disse klientene. For de kundene som ikke har betalinger, vil "Betaling"-feltet være NULL. Etter logikken, i den første midlertidige tabellen "tPayments" utpekte jeg 2 felt, ett av dem NULL, den andre linjen "Har ikke betalinger". I det tredje bordet blir jeg med indre sammenføyning tabellene "tClientPayment" og "tPayment" for feltene "Payment" og "Document". Vi vet at i den første tabellen er «Dokument»-feltet NULL, og i den andre tabellen er de som ikke har betalinger i «Betaling»-feltet også NULL. Hva vil en slik forbindelse returnere til oss? Men det vil ikke returnere noe. Fordi sammenligningen NULL = NULL ikke evalueres til True.

For at forespørselen skal returnere det forventede resultatet, la oss skrive det om:

VELG "Ingen betalinger" AS Attribut, VALUE(Document.Payment.EmptyLink) AS Document PLACE toPayments; ////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(Payment.Link, VALUE(Document.Payment.EmptyLink )) HVORDAN Betaling PUT tClientPayment FROM Directory.Clients AS Clients LEFT CONNECTION Document.Payment AS Payment BY Clients.Link = Payment.Shareholder; ////////////////////////////////////////////// //////////////////////////// select tclientpayment.client from tclientpayment as tclientpayment internt join tpayment as ttopay by tclientpayment.payment = tpayment

Nå, i den andre midlertidige tabellen, har vi indikert at hvis "Betaling"-feltet er NULL, så er dette feltet en tom lenke til betalingsdokumentet. I den første tabellen erstattet vi også NULL med en tom referanse. Nå involverer tilkoblingen ikke-NULL-felt og forespørselen vil returnere det forventede resultatet.

Alle forespørsler i artikkelen gjenspeiler situasjonene jeg ønsker å vurdere og ingenting mer. OM De er kanskje ikke vrangforestillinger eller suboptimale, det viktigste er at de gjenspeiler essensen i eksemplet.

13. Et udokumentert trekk ved "CHOICE WHEN...THEN...END"-designet.

I tilfelle det er nødvendig å beskrive "Betingelser"-konstruksjonen i forespørselen, bruker vi standardsyntaksen:

VELG UTVALG NÅR Users.Name = "Vasya Pupkin" SÅ "Vår favorittansatt" ELSE "Vi vet ikke dette" END AS Field1 FROM Directory.Users AS Users

Men hva om vi for eksempel trenger å få månedens navn i en forespørsel? Å skrive en stor konstruksjon i en forespørsel er stygg og tidkrevende, så denne formen for skriving ovenfor kan hjelpe oss:

SELECT MONTH(US_CalculationConsumption_TurnoverSchedule.CalculationPeriod) NÅR 1 SÅ "Januar" NÅR 2 SÅ "FEBRUAR" NÅR 3. SÅ "MARS" NÅR 4. SÅ "April" NÅR 5. SÅ "6. MAI" NÅR JUNI "NÅR JUNI" 8. SÅ "August" NÅR 9. SÅ "September" NÅR 10. SÅ "Oktober" NÅR 11. SÅ

Nå ser designet mindre tungvint ut og er lett å forstå.

14. Batch-utførelse av spørringer.

For ikke å multiplisere forespørsler kan du lage én stor forespørsel, dele den opp i pakker og jobbe med den.
For eksempel må jeg hente følgende felt fra "Brukere"-katalogen: "Fødselsdato" og de tilgjengelige rollene for hver bruker. last opp dette til ulike tabelldeler på skjemaet. Selvfølgelig kan du gjøre dette i én forespørsel, så må du iterere gjennom postene eller skjule dem, eller du kan gjøre dette:

SELECT Users.Link AS Fullt navn, Users.Fødselsdato, Users.Role PUT vtUsers FROM Directory.Users AS Users; ////////////////////////////////////////////// ////////////////////////// SELECT tueUsers.Full navn, tueUsers.Fødselsdato FROM tueUsers AS tueUsers GROUP BY tueUsers.fullt navn, tueUsers . Fødselsdato; ////////////////////////////////////////////// //////////////////////////// select wusers.full name, wusers.role from wusers as wusers group by wusers.full name, wusers av fødsel

tPackage = Request.ExecutePackage();

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

Som vi kan se, kan spørringen utføres i en batch og resultatet kan behandles som en matrise. I noen tilfeller er det veldig praktisk.

15. Betingelser i en batchforespørsel

For eksempel har vi en batchforespørsel, hvor vi først får feltene: «Navn, Fødselsdato, Kode» fra «Brukere»-katalogen og ønsker å hente poster med betingelser for disse feltene fra «Individualer»-katalogen.

SELECT Users.Individual.Name AS Name, Users.Individual.Date of Birth AS Fødselsdato, Users.Individual.Code AS Kode PLASS vtUsers FRA Directory.Users AS Users; ////////////////////////////////////////////// /////////////////////////// r r

Du kan stille vilkår som dette:

WHERE Individuals.Code IN (SELECT tueUsers.Code FROM tueUsers) OG Individuals.Name IN (SELECT tueUsers.Code FROM tueUsers) OG Individuals.BirthDate IN (SELECT tueUsers.DateBirth FROM tueUsers)

Og du kan gjøre det slik:

HVOR (Individuals.Code, Individuals.Name, Individuals.Date of Birth) IN (SELECT tueUsers.Code, tueUsers.Name, tueUsers.Date of Birth FROM tueUsers)

Dessuten er det nødvendig å opprettholde orden.

16. Ringe spørringsbyggeren for "tilstand" i en batchforespørsel

Når det er nødvendig å pålegge en betingelse, som i eksemplet ovenfor, kan du glemme hvordan dette eller det feltet kalles i den virtuelle tabellen.
For eksempel må du pålegge en betingelse i "Fødselsdato"-feltet, og i den virtuelle tabellen kalles dette feltet "Debitors fødselsdato", og hvis du glemmer navnet, må du avslutte redigering av betingelsen uten lagre og se på navnet på feltet. For å unngå dette kan du bruke følgende teknikk.

Det er nødvendig å sette parenteser etter konstruksjon "B" og la et tomt mellomrom (mellomrom) mellom parentesene, velg denne plassen og kall opp spørringskonstruktøren. Designeren vil ha tilgang til alle tabellene i batch-spørringen. Teknikken fungerer både på virtuelle registertabeller og på fanen "Betingelser". I sistnevnte tilfelle må du merke av i boksen "P (vilkårlig tilstand)" og gå inn i redigeringsmodusen "F4".

Forespørslene ble ofte gjort på flukt, og de tjener ganske enkelt til å illustrere "teknikkene" som jeg vurderte.

Jeg ønsket å se på bruken av indekser i spørringer, men dette er et veldig bredt tema. Jeg legger det inn i en egen artikkel, eller legger det til her senere.

oppd1. Poeng 11,12
oppd2. Poeng 13,14,15,16

Brukte bøker:
Spørrespråk "1C:Enterprise 8" - E.Yu. Khrustaleva
Faglig utvikling i 1C:Enterprise 8-systemet."