Hogyan lehet megtalálni az 1. sorban lévő szimbólum előfordulását. Mi az általunk végrehajtott rendszer

Ebben a cikkben elmondom a gyorskeresés funkcióját 1c Enterprise 8. Mi a gyors keresés? Nagyon egyszerű. A gyors keresés az 1C rekordok nagy listájának navigálásának egyik módja. Ezek lehetnek dokumentumok, könyvtárak, nyilvántartások mindazok, amelyeket táblák képviselnek.

Mi a gyors keresés?

Az 1C-ek gyorskeresési funkciója rendkívül kényelmes, és lehetővé teszi, hogy ne görgethessen a hatalmas adathordozókon (például a görgetősáv használatával), és azonnal menjen a kívánt helyre a listában. Sajnos az 1C Enterprise 8 (beleértve az 1c számviteli 8) kezdő felhasználói kezdetben nem használják a gyors keresési képességet, előnyben részesítve a dokumentumok manuális lefordítását (és lehetnek magasan nagy). Ez a cikk segít az 1C-ben történő gyors keresés használatával foglalkozni.

Először is meg kell jegyezni, hogy az 1C-es vállalati 8 konfigurációiban a kezelt formákra épített, gyors keresési működik, mint a előző verziók 1c. Ezért elemezzük külön a gyors keresés használatát kezelt formák és rendes.

Gyorskeresés az 1c-es számvitelben 8.2

Az 1C-es számviteli verziókban 8,0 és 8,2 között A funkció célja Átmenet A lista kívánt részéhez. Például nézze meg az ábrán látható fiókterv ablakát.

Az ablak kiemelte a sorokat. Figyeljen a jogosulatlan háromszögre a csíkoktól, amelyekhez a piros nyíl jelzi. Mint más Windows programokban, ahol vannak listák (például a karmesterben), ennek a markernek (háromszögnek) meghatározza a lista egészének rendezését - melyik oszlopban van telepítve, ugyanazon és a teljes listán lesz rendezve. Az ábrán a jelölő a Kód oszlopban van, ezért a számla számlát a kód szerint rendezi.

A marker egy oszlopról a másikra mozgatható, ügyetlen a kívánt oszlopon ( a fejlécoszlopon!) Egér. Ha a marker már áll az aktuális oszlopban, akkor a kattintás az ellenkező irányba változó változáshoz vezet (azaz egy kisebb vagy annál kisebb vagy fordítva). Ez a szokásos viselkedés minden windows programok. Mi a jelölő jellemzője az 1C-es vállalkozásban, és hogyan kapcsolódik a gyors kereséshez?

Gyorskeresés az 1c-es listákban A 8-as vállalat oszlopon történik, amelyben a marker áll. Ebben az esetben a fiókterv gyorskeresése oszlopkóddal történik.

Itt volt fontos rész Cikkek, de JavaScript nélkül nem látható!

Hogyan élvezhet gyors keresést az 1C-ben? Könnyen! Csak nyomtassa ki, mit szeretne találni ebben az oszlopban.. Ahol van egy marker. A példában a fenti ábrán meg kell adnia a számlaszámot. Például 50 pénztáros pontszámot szeretne találni. Ebben az esetben adja meg ( egér kattintás nincs bárhol!) Az 50-es szám a billentyűzetről, és ha ebben az oszlopban van egy fiók ugyanazzal a számmal (és ez természetesen), akkor a lista görgeti erre a vonalra, és maga a karakterlánc külön lesz. Az eredmény az alábbi fiókterv képernyőképe látható.

weboldal_

Az a szöveg, amelyen a nyíl jelzi, nem kell mosni - eltűnik.

Ha elkezdi beírni a "Ticket" szót a fenti példában, akkor az ablak alján található szöveg kerül beírásra, majd halmozódik le. Ez történik, mert amint rajt A megadott gyorskeresési karakterlánc megszűnik, hogy megfeleljen az oszlopban lévő legalább egy vonal kezdetének, az 1C-os vállalat arra a következtetésre jut, hogy a kívánt vonal nem található, és automatikusan törli. Vonatkozó emlékeznie kell két szabályt.

Az 1C Vállalkozás 8-ban a sor kezdetén gyors keresést végeznek, azaz Az oszlopot a bemeneti szöveg egybeesését keresi az oszlop egyik sorának kezdetével.
Ez fontos ajánlásra vonatkozik: az adatok referenciakönyvekbe történő beírásakor hívja fel az elemeket, hogy kényelmes legyen a gyors kereséshez. Például az ügyfél neve jobb, ha "NAMEFIRMA LLC", mint "LLC NAMEFIMA). És még inkább, ne használjon idézeteket és egyéb felesleges karaktereket a névben (a név betöltéséről beszélünk).

Ha elkezdte beírni a szöveget, és törli - amit keresel, hiányzik ebben az oszlopban! Ebben az esetben ellenőrizze a bemeneti nyelvet, valamint az oszlopot, amelyben gyors keresés készült. Egy tipikus hiba - nem az oszlop kiválasztása. Például a jelölő a Kód oszlopban van telepítve, és a keresés a fiók nevével történik.

Gyorskeresés az 1c számvitelben 8.3

Most nézzük meg, mi a különbség a gyorskeresés között az 1C Vállalat 8.3 verziójában. A használat nagyrészt hasonló a 8.2-es verzióhoz, de van egy jelentős különbség, amelyet meg kell emlékezni.

Az 1c számviteli 8.3, valamint a kezelt formák bármely más konfigurációjában (az egyik Új felület) Úgy működik, mint egy szűrő. Egyszerűen tegye, a gyorskeresési funkció eredményeként a lista része bujkál.

Hogyan kell használni, most meg fogjuk találni veled. Kezdjük, nézd meg az 1c számviteli számviteli számviteli terv screenshotját, amely az alábbiakban csökkent.

weboldal_

Amint láthatja, ugyanazt a jelzőt az egyik oszlopban. A keresést az oszlop is elvégzi, amelyben a marker telepítve van. Mindent változatlan marad. Ha azonban beírja a szöveget (a példa, a számlaszám), akkor a következők fordulnak elő.

weboldal_

Amint látható, a keresőmező egyszerűen automatikusan megnyílt. Ugyanez az ablak megnyílik, ha az ablakban található keresőgombra kattintva (az ábrán aláhúzva). Ennek eredményeként, amikor rákattint a Keresési ablakra, keresse meg a találatot (a képen el van rejtve a legördülő menü mögött), vagy csak írja be, majd kapja meg a következő eredményt.

weboldal_

Úgy tűnik, hogy a gyorskeresés az 1c számvitelben 8.3 Csak elhagyja a lista látható részét, amely megfelel a keresési feltételeknek. Ebben az esetben a keresés gomb eltűnik, és ehelyett egy keresztmetszetű lencse (az 1. ábrán látható), amikor rákattint, hogy a lista visszatér-e a kezdeti állapot (Ez továbbra is kiemeli a gyorskeresés eredményeként található karakterláncot).

A gyors keresés egyik fontos jellemzője az 1c számvitelben 8.3 - A véletlen egybeesés nem keresi a vonal tetején, mint a 8.2-es verzióban, de egy véletlen egybeesés az oszlop sorai bármely részével. Így, ha a másik fél az úgynevezett „Ltd.phirma LLC”, és ha keres kezdeni belépő „Namefirma LLC”, akkor is lesz egy húr!

Következtetéseket vonunk le

Így egy gyors keresés az 1c számviteli 8.2 és a korábbi verziókban a listán keresztül görgethető a kívánt sorba, és az 1C-ben a 8.3.

Zajitorikus fő jegyzetek

02/07/2013 Lock keresés

A 8.3.3.641-es verzióban végrehajtott.

Komolyan javítottuk a vonal bemenetét. Ehhez új erőteljes keresési mechanizmust kellett végrehajtanunk a beviteli mezőben. Most gyorsan együttműködhet az adatbázisban található rekordok millióiban.

Elemeztük a felhasználóktól származó keresés feladatait. A különböző keresési algoritmusokat alkalmazó platform mechanizmusainak ellenőrzését végezte. Ennek eredményeként a sorba lépve minőségi lehetőségeket szerzett.

A felhasználók most kereshetnek bárhol a névben, és nem csak a vonal elején. A teljes szöveges keresést használhatják, és a keresést háttérfeladattal is elvégezhetik. Annak érdekében, hogy a teljes szöveges keresést hatékonyan működnek, amikor belépnek a sorban, mi emellett optimalizált ezt keresési mechanizmust és növelte teljesítményét.

Minden olyan új tulajdonság, amely lehetővé teszi, hogy beállítsa a bemenetet a vonalon, külön könyvjelzővel gyűjtöttük össze a konfigurációs objektum szerkesztéséhez szükséges ablakot:

Például meghatározhatja, hogy a keresés a sorban bárhol történik, és nem csak az elején:

Ezután a felhasználó a szavak bármilyen töredékeit toborozhatja, és nem csak azokat a szimbólumokat, amelyekből a keresett karakterlánc kezdődik:

A teljes szöveges keresés használata a vonal beírásakor különálló tulajdonsággal aktiválódik:

A teljes szöveges keresés használatával a felhasználók nagy adatmennyiségeket tudnak gyorsan megtalálni a megfelelő adatokat a foglalt szavak bármelyikén, például a névben:

Több híres szó is kereshetnek. A befejezetlen szavakat automatikusan kiegészíti a lehetséges kombinációkkal:

Ha az adatok nagyszerűek, akkor mindkét esetben megadhatják, hogy a keresést a háttérfeladattal kell elvégezni:

Ezután a bemeneti mező mellett az animált kép jelenik meg a felhasználók számára, hasonló képhez, amely megjelenik a jelentés megjelenésekor:

• ha a beviteli mezőben használt objektumban nem várható nagy mennyiségű adat, azt javasoljuk, hogy engedélyezze a karakterlánc keresését bárhol;
• ha az objektumot tervezik nagyszámú Adatok akkor:
  • javasoljuk, hogy teljes szöveges és háttérkeresést tartalmazzon;
  • ugyanakkor bárhol is használhatja a karakterlánc keresését, hanem a háttérkeresést és előnyösen teljes szöveges keresést; A teljes szöveges keresés során végzett keresések többségéhez.

Minden felsorolt \u200b\u200btulajdonság, ha szükséges, felülbírálhatja az alkalmazott megoldás végrehajtásának folyamatát.

Az ügyfélen - az ügyfélbeviteli mező eseménykezelőkben Automatikus) és Exquisites :

A kiszolgálón - a menedzser menedzser moduljában, amelyben a keresés végrehajtása. Az eseménykezelőben Eljárás :

Természetesen, ebben a helyen, a kiszolgálón, lehetetlen felülírni a keresési módszert "Közvetlenül" vagy "Háttérfelosztás" . Mivel a kódfuttatás már átkerül a kiszolgálóra.

Sor - az egyik primitív típusok Adatok az 1C rendszerekben: Vállalat 8. változók típusú vonal szöveget tartalmaz.

A típusváltozók értékei vonalcsatolt kettős idézetek. Több változó ez a típus hajtható össze.

PER1 \u003d "Word 1";
PER2 \u003d "Word 2";
PER3 \u003d PER1 + "" + PER2;

Végül is Per3. fontos lesz Word 1 Word 2 ".

Ezenkívül az 1c-os rendszerekben: A 8-as vállalat a vonalakkal való együttműködés funkcióit biztosítja. Fontolja meg a fő:

Belép (<Строка>, <Подсказка>, <Длина>, <Многострочность>) — a funkció úgy van kialakítva, hogy egy párbeszédpanel adjon ki, amelyben a felhasználó megadhatja az értéket változó típus Vonal. Paraméter <Строка> kötelező, és tartalmazza a változó nevét, amelyben a bevezetett karakterláncot rögzítik. Paraméter <Подсказка> opcionális a cím párbeszédpanel. Paraméter <Длина> opcionális, műsorok maximális hossza Belépett vonalak. Az alapértelmezett érték nulla, ami korlátlan hosszúságot jelent. Paraméter <Многострочность> választható. Adja meg a bemeneti módot többsoros szöveg: Igazság - Adja meg a többsoros szöveget vonalak elválasztókkal; LIE - írjon be egy egyszerű vonalat.

A karakterlánc beírható, és az ENICODE kódolás szimbólumkódjának ismerete:

Szimbólum(<КодСимвола>) — a kód számként kerül beírásra.

Letter \u003d szimbólum (1103); // i

Van egy fordított funkció is, amely lehetővé teszi, hogy megtalálja a szimbólum kódját.

Codeimvol (<Строка>, <НомерСимвола>) — visszaadja a meghatározott szimbólum számát az Unicode kódolásában egy szám formájában.

Szöveges regiszter konverziós funkciók:

Vega (<Строка>) - Az összes karakterláncot a felső regiszterre konvertálja.

Nega (<Строка>) - Az összes karakterláncot a kisbetűkre konvertálja.

Trega (<Строка>) - Átalakítja az összes string szimbólumot a címsorban. Ez az, hogy az első betűk az összes szóban a nagybetűs, és a fennmaradó betűk az alsó.

Keresés és csere karakterek a karakterláncban:

Megtalálni(<Строка>, <ПодстрокаПоиска>) - Keresse meg a keresési szubsztrálás karakterét. Például:

Keresse meg ("string", "oka"); // négy

Stret<Строка>, <ПодстрокаПоиска>, <НаправлениеПоиска>, <НачальнаяПозиция>, <НомерВхождения>) - A keresési szubsztrálás keresési számának megkeresése, a belépési szám a megfelelő paraméterben jelenik meg. Ebben az esetben a keresés olyan szimbólummal kezdődik, amelynek száma a paraméterben van megadva Telepítés.A keresés a vonal végétől vagy végétől lehetséges. Például:

NUMBER4 BEÁLLÍTÁS \u003d STRNET ( "Halál", "O", irány. Első, 1, 4); // 7.

Strost (<Строка>, <ПодстрокаПоиска>, <ПодстрокаЗамены>) - Az eredeti sorban megtalálható a keresési szubsztrálás összes bejegyzése és a csere helyettesítésére.

Strost ("string", "oka", ""); // oldal

Üres vonal (<Строка>) - Ellenőrzi a karakterláncot jelentős karakterek jelenlétére. Ha nincs értelmetlen karakter, vagy nincsenek karakterek, akkor az érték visszatért Igaz. Másképp - Hamis.

Arckoring (<Строка>, <ПодстрокаПоиска>) - kiszámítja a keresési szőrzet előfordulásainak számát a forrásvonalban.

Arckoring ( "Tanulmányozni, tanulmányozni és tanulmányozni újra", "tanulni" , "" ) ; // 3.

Strarb (<Строка>, <ЗначениеПодстановки1>…<ЗначениеПодстановкиN> — a karakterlánc paramétereit a szám szerint kell elhelyezni. A karakterláncnak tartalmaznia kell az űrlap helyettesítési markereket: "% 1.% N". A számozási jelölők 1-vel kezdődnek, ha a paraméter értéke Határozatlan, Az üres karakterlánc szubsztituálva van.

Strarb ( "1. paraméter \u003d% 1, 2. paraméter \u003d% 2", "1" , "2" ) ; // 1 \u003d 1 paraméter, 2 \u003d 2 paraméter

Soros konverziós funkciók:

Egy oroszlán(<Строка>, <ЧислоСимволов>) - Visszaadja az első első karakterláncot.

Jogok (<Строка>, <ЧислоСимволов>) - Visszaadja a legújabb karakterláncokat.

Környezet (<Строка>, <НачальныйНомер>, <ЧислоСимволов>) - Visszatér egy karakterláncot<ЧислоСимволов>A szimbólummal kezdődően<НачальныйНомер>.

Sokrel (<Строка>) — Vágja ki a jelentéktelen karaktereket az első jelentés szimbólum bal oldalán a sorban.

COPP (<Строка>) - A karakterlánc utolsó jelentős szimbólumának jobb oldalán levágja a jelentéktelen karaktereket.

Sokrlp (<Строка>) - A sorban lévő első jelentés szimbólum bal oldalán és az utolsó jelentős szimbólum jobb oldalán levágása.

Plotchikstka (<Строка>, <НомерСтроки>) - Számos soros karakterláncot kap.

Más funkciók:

Strdlin (<Строка>) - Visszaadja a karakterlánc karakterek számát.

Strokelost (<Строка>) - Visszaadja a sorok számát egy többsoros karakterláncban. A karakterlánc újnak tekinthető, ha az előző sorfordítási szimbólumtól elválasztható.

(<Строка1>, <Строка2> ) - összehasonlítja két vonalat regisztráció nélkül. A funkció hasonlóan működik az objektumhoz Összehasonlítás. Visszatérés:

• 1 - Ha az első sor nagyobb, mint a második
• -1 - Ha a második sor nagyobb, mint az első
• 0 - ha a sorok egyenlőek

Sztrájk ("első sor", "második karakterlánc"); //

A nevem Pavel Barkets, a SoftPoint-on dolgozom. Több mint 10 éve megoldottuk a teljesítmény optimalizálási feladatokat. És a sok megoldott problémák nagy száma ellenére, számuk nem csökken, de a geometriai progresszióban nő. Az adatmennyiségek növekedése, valamint az adatok optimalizálására szolgáló feladatok bonyolultak. Ez a folyamat elkerülhetetlen.

Cikk téma - az optimalizálással kapcsolatos nem triviális megközelítések. Figyelembe fogják venni két szempont:

• Első - stressz keresése. A felhasználók gyakran használják, és sokan, valószínűleg már jelentős várakozással találkoztak, az aljzat keresése nem elég.
• Másodszor - nagy dokumentumok végrehajtása, például a hónap lezárása, a költség kiszámítása. Bizonyára sokan találkoznak az a tény, hogy a könyvelők tölteni ezeket a dokumentumokat 5-9 órát, éjjel, és nincs idő. A legérdekesebb dolog az, hogy a klasszikus optimalizálási módszerek nem mindig segítenek. Ha az ilyen dokumentumok lebonyolításakor fut a hibakereső mérési mérés során, látni fogja ezt a legnagyobb szám Az idő átmeneti vagy valós struktúrákra történő írásra fordítva - asztalok, nyilvántartások stb. És lehetetlen megoldani ezt a feladatot klasszikus módszerekkel.

Stressz keresése

Első téma - stressz keresése. Ebben az évben többször találkoztam a művelettel kapcsolatos problémákkal. A biztosítási társaságba jutsz a politika kiterjesztéséért, akkor felajánlja, hogy megtalálja a telefonszámot. Nyilvánvaló, hogy ez nem klasszikus keresés A telefon teljes számán, mert a felhasználónak lehet egy szám a nyolc, a hét vagy valahogyan, ezért keresi a szoba számát. Ebben az esetben hosszú távú keresési műveleteket használnak - számos helyzetben a késedelem néhány másodperc lehet, és akár percekig is jön.

A kezdeti karakterek keresése

Elkezdem az első példával, ha a keresést kezdeti karakterekkel végzik. Ez egy különleges eset, ha a felhasználó megtalálja az aljzatot, ha a felhasználó tudja, hogy a kívánt érték bizonyos karakterekkel kezdődik.

A kezdeti karakterek keresése 1c-ben valósul meg a csapat segítségével (vagy egy angol változatban, mint például), jelezve a "%" értéket a végén ("%" bármely más karakter szekvenciáját jelöli). Például keresünk:

Név, mint "Ivano%"

Kérjük, vegye figyelembe, hogy ha van egy indexe ezen a mezőben a rendszerben, akkor az indexkereset az SQL lekérdezésben kerül felhasználásra - Ez az index keresése.

A "Mint a keresősáv" állapot megegyezik a keresés az értékek tartományában. Egy adott esetben, amikor "Ivano%" -et keresünk - ez egyenértékű a keresés a vezetéknevek körében, amely "Ivano", és végződik az "Ivanp" (mert a "P" szimbólum megy utána az "O" szimbólum).

A modern optimalizátorok önállóan konvertálják a lekérdezési kérelem lekérdezésének kérését. Ezért ha van egy indexe ezen a mezőben a rendszerben, akkor ilyen eredményt kapsz, amikor a lekérdezést az SQL Feltételek értelmében - az optimalizáló egy olyan keresletet fog benyújtani, mint egy keresési formában.

Így egy klasszikus gyorskeresést gyakorolhat egy index (indexkereső) segítségével. Nincs probléma ezzel, vagy egyszerűen megoldja őket.

Keresés a belépéshez

Most vegyen be egy példát bonyolultabb, ha ismeretlen, ahol a vonal helye a kívánt értékünk, és a soros bejegyzés keresése végrehajtásra kerül. Ebben az esetben a "hasonló" "%" lekérdezésében mindkét oldalon áll.

Ha egy ilyen lekérdezést SQL-ben konvertálunk, azt látjuk, hogy csak a parancs változik (az értékben már két "%").

Fontolja meg a végrehajtási terv részleteit. Itt ugyanazt az indexet keresjük, de ebben az esetben nem működik hatékonyan.

Az a tény, hogy az index a referenciakönyv nevét, amelyet úgy gondolunk, több területből áll.

• Az első közülük a számviteli elválasztó.
• Továbbra is a keresési mező.

És ezért, amikor az "indexkereset" a végrehajtás szempontjából jelenik meg, ez azt jelenti, hogy a keresés az elválasztó első területén történik - A fenti csúszkán láthatod ezt a kívánt DESC értékünk keresése teljesen nem használható.

Mit kell tenni ebben a helyzetben? Nagyon gyakran voltam a gyakorlatban, hogy a felhasználók tiltották a belépési kérelmeket. És a felhasználók bizonyos esetekben maguk nem használták ezt a funkcionalitást, mert a végrehajtási idő nagyon jelentős, és továbbra is dolgozni kell. Ezért más módon kellett csavarni őket - úgy döntöttek a listákban, megpróbálták megtalálni az első karaktereket és így tovább.

De ez elégedetlenséget eredményez a rendszer funkcionalitásával és helytelen érzékelésével. A felhasználó megérti, hogy a rendszer nem tud megbirkózni valamit, és nem működik, ahogy kell. Nem helyes.

A szubsztrálás megtalálásának feladatainak megoldására

Most fontolja meg nem triviális megközelítés a feladat megoldásához.

Számos tűréshatár:

• Először - Mivel a modern a lemezek korlátlan méretűek, Tegyük fel, hogy a lemezen lévő hely, amit használhat, elég nagy.
• Másodszor - a felhasználó nem keres két-két szimbólumot, hanem bizonyos fragmentumot. Például egyikünk sem keres "al" -et - túl kicsi szelektivitás. Jelentős karaktersorozatot keres. Itt a hat szimbólum keresését választottuk.

Az "Alexe" kívánt vonalának példáját az űrlapon rögzítettük, és tesztelné vele.

• Tegyük fel, hogy van egy mezője a vezetéknévvel, az ügyfél nevével és patronából. Első lépés, automatikusan elrendezzük ezt az értéket a hat szimbólum töredékéhez, egy SHIFT "1"És kapunk egy tömböt (lásd fent), amely mindig a kívánt értékhez tartozik. Fragmentumokat kaptunk, amelyek elméletileg beléphetnek a felhasználóba. Nevezetesen, a múltban a dia meghatározta, hogy hat karaktert keresünk. Lehet, hogy öt közülük, és négy, csak a szerkezet mérete több lesz.

• A második lépésben mi ezeket a készleteket külön szerkezetben írjuk le (Ez lehet asztal, információs regiszter stb.), És kaphat olyan mintát, amelyben egy bizonyos fragmens különböző értékekhez tartozik.

• És a harmadik lépésben azt, amikor keres részkarakterláncként a design 1C kérés, egy kiegészítő állapot „”, amely kiszűri a lehetséges kombinációk száma, és húzza ki ebből további struktúra (ez lehet az információs regiszter ) Az összes olyan tétel, amelyhez a szükséges töredékek tartoznak.

Például a felhasználó ügyfelet keres a "katonák" vezetéknévvel. Ez nyolc karakter, ez azt jelenti, hogy hat karakter hosszú fragmens lesz, amelyet a szolgáltatási struktúrában keresünk. Ezután kombinálja mindent a lekérdezésben. Így további szűrést kapunk.

Ennek eredményeként megszabadulunk a "%" jelektől (azaz ezeknek a töredékeknek az előtte, a szükséges szimbólumnak mindig lesz), és egy belső kérés végrehajtásakor indexek lesznek, amelyekért harcoltunk.

A gyakorlatban nagyon érdekes történetet alakít ki - gyorsulás tucatnyi, több százszor. Ráadásul mindez az 1C-vel végezhető, ami nagyon szép. Nem kell átírnia a logikát, a felhasználó örül, hogy a keresési lekérdezés felgyorsult. A példában 4 másodpercre 0,05 másodpercre gyorsulást jelent, és ha kezdetben két percig kérésünk volt, akkor kevesebb mint egy másodpercig végrehajtott volna.

Az általam kimutattam, hogy nem volt kísérleti példa, már dolgozik valódi ügyfelek számára.

Előkészítő tevékenységek

Most elmondom neked az előkészítő tevékenységeket.

• Első meg kell tölteni a nyilvántartási kezdeti értékeket.. Ehhez meg kell ütemeznie a szabályozási ablakot.
• Ezután meg kell felelnünk az adatkonzisztencianak - ez azt jelenti az érték megváltoztatásához előfizetésnek kell lennieHogy ezek a töredékek automatikusan újjáépüljenek.
• És utolsó - szabványos keresési űrlapot adjon hozzá.

A nyilvántartás kitöltése mind az 1c, mind az SQL segítségével történhet.

Azt mondhatom, hogy az ilyen struktúra töltése 17 millió értékre valahol 20-25 perc. Természetesen a felhasználók ezen a ponton nem változtathatják meg a könyvtár értékeit.

Ha a fragmentumban valahol 100 karakterből egy millió értéket számítunk ki, valahol 4,7 GB-ot kapunk. Meg kell tervezned, hogy ez a hely van. Ha a könyvtárban van, például 100 millió érték, akkor meg kell ütemeznie a lemezen elérhető helyet.

A töredékek népszerűségi statisztikáinak figyelembevételének szükségessége

Ez a módszer mindig gyorsan működik?

Ezt befolyásolja a népszerűségi töredékek statisztikái.

• Például egy "Alex" töredéke van, amely beírhatja Alexey nevét, Alekseevich középső nevéhez, Alekseenko nevében stb. Ez a töredék lehet 50-100 ezer bejegyzés.
• És ritkán használt töredékek vannak.

Így a töredékek népszerűségének statisztikája jelenik meg.

vegye figyelembe, hogy ha a töredékek népszerűsége alacsony (100 elem), akkor kapunk gyorsulást - 0,1 másodperc.

Ha az aljzat meglehetősen népszerű (50 ezer elem), akkor degradációt kapunkÉs sokkal nagyobb, mint ha nincs optimalizálás.

Ilyen módon szükséges, hogy jobb lekérdezési végrehajtási rendszert készítsenamelyben először megkaptuk a rubkészet népszerűségének értékét. Ezt három-öt vonal végzi 1c. Ugyanakkor pontosan tudjuk, hogy ha a karakterlánc népszerűtlen, akkor az első ágban, és ha népszerű, akkor a második.

Hogyan működik a gyorsulás? A keresési keresés az űrlapon keresztül történik, akkor fellebbezünk a statisztikákkal kapcsolatos információk regisztrálására, kapunk egy elemet, és további választhatunk, hogy mit használunk egy klasszikus vagy gyorsított lekérdezés.

És most nézzük meg, hogyan történik az SQL kérés az SQL Serveren.

A dia egyszerűsített sémát mutat be:

• kérés az optimalizálóhoz;
• megnézzük a kérelemben használt mezőstatisztikákat;
• kiválasztjuk, hogy melyik végrehajtási tervet használja, vagyis válassza ki a lekérdezési végrehajtási stratégiát (például a befektetett ciklus).

Mi az általunk végrehajtott rendszer?

• A sajátodat készítettük index. Nem szabványos SQL index, nem index 1c, hanem annak indexe, amely a probléma megoldásához szükséges;
• Ráadásul összeütközött azzal, amire szüksége van a sajátnak statisztika;
• És szüksége van a sajátodra optimalizálóMelyik statisztikák szerint úgy dönt, hogy melyik szál választható.

E logika alapján elmondható, hogy ez a folyamat feltárja, hogy mit jelent az indexek, statisztikák és optimalizáló számunkra.

Ki nem tudta, mit szolgálhat az SQL statisztikájában, nézze meg ezt a logikát, és meg fogja érteni, hogy ha rossz vagy irreleváns, akkor a rossz ágon megyünk. A lekérdezés lelassul. Megértjük, hogyan kell minőségi és helyesen szolgálni a statisztikákat - ez befolyásolja a termelékenységet az indexen.

Ha nincs index - minden értéket szkennelünk.

Így legalább primitív, de az optimalizálót hoztuk létre. Azt mondhatjuk, hogy nyomon követik az "ujjakon", hogy az SQL MS és más DBMS, és saját struktúráit hozza létre.

A "nagy" dokumentumok gyorsítása

A második témához megyek - a nagy dokumentumok gyorsulása.

Gyakran szembesülünk néhány szabályozási eljárással, mint: a hónap zárása, az ügynök jelentés, a költség kiszámítása. Ezeket a nehéz, hatalmas dokumentumokat elvégzik, és jelentős időt töltenek ki. És amikor megnézzük a hibakeresést, és nyomon követjük ezeket a műveleteket, ezt látjuk Az 1c vonal beilleszti az értékeket egy táblázatba, és a fő idő ők.. És lehetetlen semmit tenni róla. Az egyetlen ajánlás, amely felajánlható, hogy felgyorsítsa a lemezt (a megoldás hatékonysága nagyon kétes, és előzetes elemzést igényel).

Azt javaslom, hogy visszatérjek a történethez, és fontolja meg, hogyan történt az 1C-ben, 8,0-ről 8.3-ra kezdve - ez vonal végzett. Az SQL Server minden alkalommal elemezte a kérést, feldolgozta azt, létrehozta a végrehajtási tervet, hozzáadva, elküldte a parancsot 1C-re, és megkapta a következő kérést. És az ilyen lépésről lépésre 1c alkalmazáskiszolgálóból sétált SQL-re.

Nyilvánvaló, hogy ha 40 rekord van a dokumentumban, nincs probléma. Ha 10 ezer és több rekord van (vannak olyan szervezetek, ahol a szabályozási dokumentumokban, egy millió rekord), akkor ez a folyamat nagyon hosszú időt vesz igénybe. Egy bejegyzést nagyon gyorsan feldolgoznak, de a dokumentumban túl sok. Mi a fejjel? A hálózaton, a lekérdezés végrehajtására, a visszatérési jelre, az 1C-rendszeren lévő jel feldolgozására, a négy lépés összege. Minden szakaszot összegeznek, egy millió sort szaporítanak, és hosszú távú elvárásainkat kapjuk. Nyilvánvaló, hogy ez nem szörnyű.

Az 1C-ben a 8.3-tól kezdődően javulnak. Most az ideiglenes táblákra és az információs nyilvántartásokba való beillesztésre irányuló kérés az SQL szerveren készül, és további végrehajtása a klasszikus RPC-hívások segítségével történik, ahol az 1C hozzáférési szolgáltató maga (natív vagy OLE DB) csoportok rögzítik és beillesztik őket n húrok (általában 100 sor).

Így a gyorsulás 30% -ról 300% -ra érhető el. De még mindig nem elég, mert ma 10 ezer vonal van, holnap 20 ezer vonal. Ez nem alapvető megoldás a problémára, még mindig találkozol, de csak hat hónap / év.

Mit a leggyorsabb betét Az SQL Serverben, és valóban bármilyen DBM-ben?

azt Ömlesztett betét.. 1c ömlesztett betétet használnak, de más feladatokhoz. A "Big" dokumentumokkal való együttműködés is felgyorsulnánk a betét betétek konszolidálásával és az SQL Server adatbázishoz egyetlen tömbben is.

Lássuk, milyen hatással van. Ebben a példában kapott gyorsulás valahol 5 alkalommal, de felgyorsíthatja és 10-szer. Elméletileg a fő probléma, hogy felgyorsuljon, sokkal erősebb - ez a lemez sebessége. A lemez lehet szűk keresztmetszet.

Is fontos, hogy emlékezzen ilyen kritériumra indexekként.. Ha a táblázatban az ömlesztett betétet az indexek frissítése nélkül helyeztük be, akkor jelentős gyorsulást kapnánk (az eredmény kevesebb, mint egy második). Itt kapunk 69 másodpercet annak a ténynek, hogy a táblázat minden behelyezése megköveteli a frissítési indexet.

Mindenesetre ez a módszer lehetővé teszi 5-10-szeres hatás elérését.

Ráadásul az ilyen lehetőségeket itt nem tekintik fel a partícionálásnak, a partícionálásnak. Lehetőség lenne a helyzet javítása, ha tudnánk, hogy az ömlesztett betétet behelyezték az aktuális időszakra, és kihoznánk az irreleváns partíciót egy másik partíciónak. Még nagyobb hatás lenne. Kiderül, hogy a gyorsulás nagyon jó.

Az optimalizálási lehetőségek végtelenek

Ilyen módon az optimalizálási lehetőségek végtelenek. Az egyetlen dolog nem az, hogy bevonjon. Az optimalizálás előtt mindig értelme kiszámítani, hogy a tervezett hatás sem lesz. Azt is tanácsolnám néhány olyan helyzetben, hogy "emelkedj" a probléma felett, ne használjon klasszikus módszereket a kérelem optimalizálására, és néhány teljesen más, ami jelentősebb eredményt hozhat.

****************

Ezt a cikket a jelentés () jelentése szerint írja az Infostart Event 2017 közösségi konferencián.