Біріктіру жағдайында пайдаланылатын барлық өрістер индекс өрістері ретінде көрсетілуі керек.

2. Виртуалды кестелермен біріктіру Егер сұрау 1C: Enterprise сұрау тілінің виртуалды кестесіне қосылымды пайдаланса (мысалы, « Аккумуляцияларды.Өнімдерді.Қалдыруларды() тіркеңіз

«) және сұрау қанағаттанарлықсыз өнімділікпен орындалса, виртуалды кестеге қоңырау шалуды бөлек сұрауға жасап, нәтижелерді уақытша кестеде сақтау ұсынылады. Яғни, ішкі сұраумен қосылу жағдайындағыдай ұсынысты пайдалану керек (1-тармақты қараңыз).

Өйткені, 1С: Enterprise сұраныс тілінде қолданылатын виртуалды кестелерді SQL тіліне аударған кезде ішкі сұрауларға кеңейтуге болады. Себебі виртуалды кесте жиі (бірақ әрқашан емес) бірнеше физикалық ДҚБЖ кестелерінен деректерді қабылдайды. Егер сіз виртуалды кестемен біріктіруді пайдалансаңыз, онда SQL деңгейінде ол кейбір жағдайларда ішкі сұраумен біріктіру ретінде жүзеге асырылуы мүмкін. Бұл жағдайда ДҚБЖ оңтайландырғышы оңтайлы емес жоспарды 1С:Кәсіпорын тілінде анық қолданылатын ішкі сұраумен жұмыс істегендегідей таңдай алады.

3. Индекстер мен сұрау шарттары арасындағы сәйкессіздік

• Шарттар сұраудың келесі бөлімдерінде қолданылады:<условие>
• ТАҢДАУ... ҚАЙДАН... ҚАЙДА<условие>
• ҚОСЫЛУ... БОЙ<ВиртуальнаяТаблица>(, <условие>)
• SELECT... FROM<условие>

БАР

• Сұрауда пайдаланылатын барлық осы шарттар үшін деректерді шарт бойынша таңдауды оңтайландыру үшін қолайлы сәйкес индекстер болуы керек. Сонымен қатар, қолайлы индекс келесі талаптарды қанағаттандыратын көрсеткіш болып табылады: 1-талап
• . Индекс шартта көрсетілген барлық өрістерді қамтиды;Талап
• 2. Бұл өрістер индекстің ең басында; 3-талап

. Бұл өрістер қатарда, яғни сұрау шартына қатыспаған өрістер олардың арасында «сына» салынбаған;

• 1С: Enterprise жасаған негізгі индекстер:бірегей идентификатор бойынша индекс
• (сілтеме) барлық объектілер үшін (анықтамалар, құжаттар және т.б.);тіркеуші индексі
• (құжатқа сілтеме) тіркеушіге бағынысты тізілім қозғалысының кестелері үшін;барлық өлшемдердің периоды мен мәндерінің индексі
• жинақтау регистрлерінің жиынтық кестелері үшін;, индекстік кезеңесеп және құндылықтар

Автоматты түрде жасалған индекстер жеткіліксіз болған жағдайда, конфигуратордағы метадеректер нысанының мәліметтерін қосымша индекстеуге болады. Дегенмен, индексті құру ақпаратты іздеу процесін тездететінін есте ұстаған жөн, бірақ 1С кәсіпорнын іске қосу режимінде пайдаланушының оны өзгерту процесін (қосу, өңдеу және жою) біршама баяулатуы мүмкін. Сондықтан, индекстер саналы түрде және мұндай индекс қажет сұраныс нақты белгілі болған жағдайда ғана жасалуы керек. Сіз «болған жағдайда» индекстерді немесе әдейі артық индекстерді жасамауыңыз керек. Мысалы, тізілімнің бірінші өлшемін ешқашан қосымша индекстеуге болмайды, себебі платформа автоматты түрде жасайтын қорытындылар кестесінің негізгі индексі бірінші өлшемнің мәні бойынша іздеуге жарамды.

Конфигурация жинақтау регистрін сипаттайды Қоймалардағы өнімдер:

Сурет 1. Қоймалардағы тауарларды жинақтау тізілімінің құрылымының мысалы

1С: Кәсіпорын платформасы осы тізілімнің баланстық кестесі үшін кезең және барлық өлшемдер бойынша конфигураторда көрсетілген ретпен автоматты түрде индекс жасайды.

Бірнеше мысал сұрауларды қарастырайық және оларды осы деректер құрылымымен оңтайлы орындауға болатынын талдаймыз.

Сұраныс 1

Бұл жағдайда 2-талап бұзылған жағдайда, индекстің бірінші өрісі бойынша таңдау жоқ (Қойма). Мұндай сұраныс оңтайлы орындалмайды. Оны орындау үшін ДҚБЖ серверіне кестедегі барлық жазбаларды қайталау (сканерлеу) қажет болады. Бұл операцияның орындалу уақыты регистрдің қалдық кестесіндегі жазбалар санына тікелей байланысты және өте үлкен болуы мүмкін (және деректер көлемі өскен сайын артады).

Оңтайландыру опциялары:

• «Номенклатура» өлшемін индекстеу
• «Номенклатура» өлшемін өлшемдер тізімінде бірінші орналастырыңыз. Бұл әдісті қолданғанда абай болыңыз. Конфигурацияда осы своп арқылы баяулауы мүмкін басқа сұраулар болуы мүмкін.

Сұраныс 2

Бұл жағдайда 3-талап бұзылған «Қойма» және «Сапа» өлшемдері арасында сұрау шартында көрсетілмеген «Номенклатура» өлшемі бар. Бұл сұрау да оңтайлы орындала алмайды. Орындалған кезде ДҚБЖ индекстің бірінші өрісін іздейді, бірақ кейін оның кейбір бөлігін сканерлеуге мәжбүр болады. Сканерлеу сұраныстың орындалу уақытының ұлғаюына және кестедегі артық жазбалардың блокталуына, яғни жалпы жүйе өткізу қабілетінің төмендеуіне әкеледі.

Оңтайландыру опциялары:

• Сұранысқа «Номенклатура» өлшеміне шарт қосыңыз
• Сұраудан «Сапа» өлшеміне арналған шартты алып тастаңыз
• «Номенклатураны» өлшемдерден бөлшектерге көшіру
• «Номенклатура» және «Сапа» өлшемдерін ауыстырыңыз

Сұраныс 3

Бұл жағдайда индекс пен сұрауды сәйкестендіру талаптары бұзылмайды. Бұл сұранысты ДҚБЖ оңтайлы түрде орындайды. Сұраудағы шарттар реті индекстегі өрістердің ретімен сәйкес келмейтінін ескеріңіз. Бұл мәселе емес және оны ДҚБЖ қалыпты түрде өңдейді.

4. Логикалық НЕМЕСЕ шарттарда қолдану

4.1 Логикалық НЕМЕСЕ сұраудың ҚАЙДА бөлімінде пайдалану

НЕМЕСЕ сұраудың ҚАЙДА бөлімінде пайдаланбау керек. Бұл ДҚБЖ кесте индекстерін пайдалана алмауы мүмкін және сканерлеуді орындайды, бұл сұраудың орындалу уақытын және құлыптау ықтималдығын арттырады. Оның орнына бір сұрауды бірнешеге бөліп, нәтижелерді біріктіру керек.

Мысалы, сұрау

Өнімді ТАҢДАУ . Аты FROMКаталог . Өнімдер ҚАЛАЙ Өнім ҚАЙДА Мақала = "001" НЕМЕСЕМақала = "002"

сұраныспен ауыстырылуы керек

Өнімді ТАҢДАУ . Аты FROMКаталог . Өнімдер ҚАЛАЙ Өнім ҚАЙДА Мақала = "001" |БАРЛЫҒЫН БІРІКТІРУ |Өнімді таңдау . Аты FROMКаталог . Өнімдер ҚАЛАЙ Өнім ҚАЙДА Мақала = "002"

4.2. Әрқайсысы RLS бар бірнеше рөлге пайдаланушыларды тіркеу

1 МЕН RLS (Жазба Деңгей Қауіпсіздік) немесе рекордтық деңгейде құқықтарды шектеу - бұл жүйеде пайдаланушы құқықтарын орнату 1 МЕН, ол динамикалық өзгеретін деректер контекстінде пайдаланушылар үшін құқықтарды бөлуге мүмкіндік береді.

Егер конфигурация RLS шарттары бар бірнеше рөлдерді сипаттайтын болса, бір пайдаланушыға бірнеше осындай рөлді тағайындамау керек. Егер бір пайдаланушы, мысалы, RLS бар екі рөлге қосылса - бухгалтер және персонал қызметкері, онда оның барлық сұраулары орындалғанда, екі RLS шарттары логикалық НЕМЕСЕ арқылы олардың шарттарына қосылады. Осылайша, бастапқы сұрауда НЕМЕСЕ шарты болмаса да, ол RLS шарттары қосылғаннан кейін пайда болады. Мұндай сұрауды оңтайлы емес - баяу және шамадан тыс құлыптармен орындауға болады.

Оның орнына сіз «аралас» рөлді - «бухгалтер-кадрлар бөлімінің қызметкерін» жасап, оның RLS-ін шартта НЕМЕСЕ пайдалануды болдырмайтындай етіп тіркеп, пайдаланушыны осы бір рөлге қосуыңыз керек.

4. 3 Қосылым жағдайында НЕМЕСЕ пайдалану

Логикалық НЕМЕСЕ қосылым жағдайында, яғни сұраныс бағдарламалық құрал бөлімінде пайдалану ұсынылмайды. Бұл сонымен қатар оңтайлы емес жоспарды таңдауға және сұрау өнімділігінің баяулауына әкелуі мүмкін. OR қолданбай мұндай сұрауды қайта жазудың қарапайым әмбебап тәсілі жоқ. Шешіліп жатқан мәселені талдап, оны шешудің басқа алгоритмін табуға тырысу керек.

5.Біріктіру жағдайында ішкі сұрауларды пайдалану

Біріктіру жағдайында ішкі сұрауларды пайдаланбау керек. Бұл сұраудың айтарлықтай баяулауына және (кейбір жағдайларда) кейбір ДҚБЖ-да оның толық жұмыс істемеуіне әкелуі мүмкін. Біріктіру жағдайында ішкі сұрауды пайдаланатын сұраудың мысалы:

Сұраныс . Мәтін = «ТАҢДАҢЫЗ |FROM | Бағалар B кезеңі (. | МАКСИМАЛДЫ ТАҢДАУ(PricesLastMonth.Period) | Тіркелу ақпаратынан СОҢҒЫ АЙ БАҒАСЫНДА | ҚАЙДА БағаларӨткен ай.кезең< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | Ал өткен айдың бағалары.Номенклатура = Қалған тауарлар.Номенклатура |) | Қалған өнімдер ҚАЙДА. Қойма = &Қойма";

Бұл жағдайда біріктіру шартындағы ішкі сұрау алдыңғы кезеңнің соңында «соңғысының кесіндісін» алу үшін пайдаланылады. Сонымен қатар, әрбір номенклатура үшін кезең әртүрлі болуы мүмкін. Мұндай сұрауды уақытша кестелерді пайдаланып қайта жазу ұсынылады. Мысалы, мұны келесідей жасауға болады:

Сұраныс . Мәтін = " // Осы элементтер үшін алдыңғы кезеңдегі бағаларды орнатудың ең үлкен күндері |ТАҢДАУ | Қалған өнімдердің номенклатурасы. | МАКСИМУМ(Бағалар.Кезең) Кезең ретінде |ОРЫН даталары Номенклатуралар бойынша |FROM | Жинақтарды тіркеу | СОЛ ҚОСЫЛУ ТіркеуАқпарат.Бағасы Бағалар | БҚ бағалары.Номенклатура = Қалған өнімдер.Номенклатура ЖӘНЕ | Бағалар.Кезең< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | Қалған өнімдер бойынша ТОПТАУ.Номенклатура | ҚАЙДА қалған тауарлар. Қойма = &Қойма; // Табылған кезең үшін баға бойынша деректерді таңдаңыз |ТАҢДАУ | Күндер номенклатуралар бойынша. Номенклатура AS номенклатурасы, | Бағалар.Бағасы өткен айдың бағасы |FROM DateBy Номенклатуралар | СОЛ ҚОСЫЛУ ТіркеуАқпарат.Бағасы Бағалар | БҚ бағалары.Номенклатура = Қалған өнімдер.Номенклатура ЖӘНЕ | Бағалар.Кезең = Күндер бойынша номенклатуралар.Кезең " ;

6. Құрама типті өрістерден нүкте арқылы мәліметтерді қабылдау

Егер сұрау күрделі сілтеме түрінің өрісінен нүктелік мәнді пайдаланса, онда осы сұрауды орындау кезінде осы күрделі типке кіретін барлық нысан кестелеріне біріктіру орындалады. Нәтижесінде, SQL сұрау мәтінін өте күрделі етеді және оны орындау кезінде ДҚБЖ оңтайландырғышы оңтайлы емес жоспарды таңдай алады. Бұл кейбір жағдайларда елеулі өнімділік мәселелеріне және тіпті сұраудың сәтсіздігіне әкелуі мүмкін.

Атап айтқанда, тізілім тіркеушісінің мәліметтеріне қол жеткізу ұсынылмайды (мысалы, «ProductsInWarehouses.Registrar.Date») т.б. Бұл жағдайда күрделі түрдегі өрістен нүкте арқылы алынған атрибутты сұраудың қай бөлігінде пайдаланғаныңыз маңызды емес - қайтарылған өрістер тізімінде, күйде және т.б. Барлық жағдайларда бұл емдеу өнімділік проблемаларына әкелуі мүмкін.

• Құрама сілтеме түрлерінің өрістерін жасау кезінде артықшылықты болдырмаңыз. Қажет болса, берілген өрістің мүмкін болатын түрлерін көрсетіңіз. «кез келген сілтеме» немесе «кез келген құжатқа сілтеме» және т.б. түрлерін қажетсіз пайдаланбау керек. Оның орнына қолданба логикасын мұқият талдап, мәселені шешу үшін қажет өріске дәл сол ықтимал сілтеме түрлерін тағайындау керек.
• Қажет болса, өнімділік үшін ықшам сақтауды құрбан етіңіз. Егер сұрауыңызда сілтеме арқылы алынған мән қажет болса, онда бұл мәнді тікелей осы нысанда сақтауға болады. Мысалы, тізіліммен жұмыс істеу кезінде тіркеуші күні туралы ақпарат қажет болса, тізілімде сәйкес деректемелерді жасауға және құжаттарды орналастыру кезінде оған мән беруге болады. Бұл ақпараттың қайталануына және оның көлемінің біршама (аздап) ұлғаюына әкеледі, бірақ сұраныстың өнімділігі мен тұрақтылығын айтарлықтай жақсартуы мүмкін.
• Қажет болған жағдайда өнімділік үшін кодтың жинақылығы мен әмбебаптығын құрбан етіңіз. Әдетте, берілген шарттарда белгілі бір сұранысты орындау үшін берілген сілтеменің барлық мүмкін түрлері қажет емес. Бұл жағдайда EXPRESS функциясын пайдаланып ықтимал түрлердің санын шектеу керек. Егер бұл сұрау әмбебап болса және бірнеше әртүрлі жағдайларда пайдаланылса (сілтеме түрлері әртүрлі болуы мүмкін), онда сіз осы шарттарда қажетті түрді EXPRESS функциясына ауыстыра отырып, динамикалық түрде жасай аласыз. Бұл бастапқы кодтың өлшемін арттырады және мүмкін оны әмбебап етеді, бірақ сұраудың өнімділігі мен тұрақтылығын айтарлықтай жақсартады.

Мысал

Бұл сұрау тіркеушінің мәліметтеріне рұқсатты пайдаланады. Тіркеуші – 56 құжат түрінің біріне сілтеме мәндерін қабылдай алатын құрама түр өрісі.

Сұраныс . Мәтін = «ТАҢДАҢЫЗ | Сату.Тіркеуші.Нөмірі, | Сатылымдар.Тіркеуші.Күні, | Контрагент, | Сату.Саны, | Сату. Құны |FROM |ҚАЙДА...

Бұл сұраудың SQL мәтіні құжат кестелеріне 56 сол жақ біріктіруді қамтиды. Бұл сұрауды іске қосқан кезде елеулі өнімділік мәселелерін тудыруы мүмкін. Дегенмен, бұл нақты мәселені шешу үшін барлық 56 құжат түріне қосылудың қажеті жоқ. Сұраныс шарттары оны орындау кезінде тек «Тауарлар мен қызметтерді сату» және «Сатып алушының тапсырыстары» құжаттарының қозғалысы таңдалатын болады. Бұл жағдайда EXPRESS() функциясын пайдаланып қосылымдар санын шектеу арқылы сұрауды айтарлықтай жылдамдата аламыз.

Сұраныс . Мәтін = «ТАҢДАҢЫЗ | ТАҢДАУ | Содан кейін EXPRESS (Сату. Тіркеуші Құжат ретінде. Тауарлар мен қызметтерді сату). | КЕЙІН EXPRESS (Сату. Тіркеуші Құжат ретінде. Сатып алушыға тапсырыс).Нөмір | ТАҢДАУДЫ САН РЕТІНДЕ АЯҚТАЛАУ, | ТАҢДАУ | WHEN Сату Тіркеушісі LINK Document of Products and Services | ОДАН ЭКСПРЕСС (Сату. Тіркеуші Құжат ретінде. Тауарлар мен қызметтерді сату).Күні | ҚАШАН Сату.Тіркеуші СІЛтеме Құжат.Сатып алушыға тапсырыс | ОДАН ЭКСПРЕСС (Сату. Тіркеуші Құжат ретінде. Сатып алушы тапсырысы).Күні | ТАҢДАУДЫ КҮНІМЕН АЯҚТАТУ, | Контрагент, | Сату.Саны, | Сату. Құны |FROM | Жинақтарды тіркеңіз.Сату ҚАЛАЙ сату |ҚАЙДА | Сатылымдар.Тіркеуші LINK Document.Тауарлар мен қызметтерді сату | НЕМЕСЕ Sales.Registrator LINK Document.Сатып алушы тапсырыстары»;

Бұл сұрау анағұрлым ауыр және жалпылама болуы мүмкін (ол басқа жағдайларда дұрыс жұмыс істемейді - басқа тіркеуші түрінің мәндері мүмкін болған жерде). Дегенмен, орындалған кезде құжат кестелеріне тек екі қосылымды қамтитын SQL сұрауы жасалады. Мұндай сұрау бастапқы пішіндегі сұрауға қарағанда әлдеқайда жылдам және тұрақты жұмыс істейді.

7. Параметрлерді қолданбай виртуалды кестелерді сүзу

Сұрауларда виртуалды кестелерді пайдаланған кезде осы виртуалды кестеге қатысты барлық шарттарды кесте параметрлеріне беру керек. WHERE бөліміндегі шарттарды пайдаланып виртуалды кестелерді сүзгілеу ұсынылмайды, т.б. Мұндай сұрау дұрыс (функционалдық тұрғыдан) нәтижені қайтарады, бірақ ДҚБЖ үшін оны орындаудың оңтайлы жоспарын таңдау әлдеқайда қиын болады. Кейбір жағдайларда бұл ДҚБЖ оңтайландырғышындағы қателерге және сұрау өнімділігінің айтарлықтай баяулауына әкелуі мүмкін.

Мысалы, келесі сұрау виртуалды кестеден таңдау үшін сұраудың WHERE бөлімін пайдаланады.

Сұраныс . Мәтін = «ТАҢДАҢЫЗ | Номенклатура |FROM | Жинақтарды.Қоймалардағы тауарларды.Қалдықтарды() тіркеңіз |ҚАЙДА | Қойма = &Қойма»;

Бұл сұранысты орындау нәтижесінде алдымен виртуалды кестенің барлық жазбалары таңдалып алынуы мүмкін, содан кейін олардың арасынан көрсетілген шартқа сәйкес келетін бөлік таңдалады. Сұрау процесінде өте ерте алынған жазбалар санын шектеген дұрыс. Ол үшін виртуалды кестенің параметрлеріне шарттарды беру керек.

Сұраныс . Мәтін = «ТАҢДАҢЫЗ | Номенклатура |FROM | Жинақтарды тіркеу.Қоймалардағы тауарлар.Қалдықтар(, Қойма = &Қойма)";

Ресей Федерациясының Еңбек кодексінің 134-бабының ережелеріне сәйкес жұмыс берушілер тауарлар мен қызметтерге тұтынушылық бағалардың өсуіне байланысты қызметкерлерге жалақының өсуін қамтамасыз етуге міндетті. Индекстеу тәртібі (кәсіподақтың пікірін ескере отырып) ұжымдық шартта немесе ұйымның жергілікті нормативтік актісінде белгіленеді. Мақалада 1С сарапшылары «1С: Жалақы және персоналды басқару 8» 3 басылымында штаттық кестені және қызметкерлердің ағымдағы тарифтік мөлшерлемелерін қалай индекстеу керектігін айтады (орташа табысты одан әрі қайта есептеумен).

«1С: Жалақы және персоналды басқару 8» (3-ші басылым) бойынша индекстеу әдетте екі тапсырманы білдіреді:

• штаттық кестені индекстеу – штаттық кестедегі тарифтік ставкаларды кезең-кезеңмен өзгерту (егер ол бағдарламада қолданылса);
• қызметкерлердің қолданыстағы тарифтік ставкаларын индекстеу – орташа жалақыны одан әрі қайта есептеумен тарифтік ставкаларды арттыру.

Егер «1С: Жалақы және персоналды басқару 8» бағдарламасының 3 басылымы сақталған тарихы бар штаттық кестені жүргізсе, штат кестесін индекстеу мүмкін болады (Параметрлер - Кадрларды есепке алу - штаттық кестедегі өзгерістер тарихын жүргізу және штаттық кестені жүргізу жалаулары). Қызметкерлер кестесін орнату жалаушалары таңдалған).

Индексация кадр құрамын өзгерту құжатында жүзеге асырылады. Индекстелген позицияларды таңдау Позицияны өзгерту түймешігі арқылы жүзеге асырылады. Жалақыны есептеу параметрлерінде жиынтық тарифтік ставканың құрамын анықтау ретінде белгіленген көрсеткіштерді көрсету үшін «Индикаторларды толтыру» түймесін басыңыз. Бұл көрсеткіштердің мәндерін оларды индекстеу коэффициентіне көбейту арқылы индекстеуге болады (1-сурет).

Күріш. 1. Тарифтік топтар мен разрядтар (разрядтар) көрсетілген штаттық кестені индекстеу алдымен Тарифтік топты бекітуді жүзеге асыру керек (мәзір Жалақы – Тарифтік топты бекіту).

Тарифтік топтарды бекіту құжатындағы штат кестесінде тарифтік разрядтар бойынша тарифтік мөлшерлемелердің өзгеруін көрсету үшін «Штат кестесін өзгерту» түймесін басыңыз. Бұл жағдайда штаттық кестені өзгерту құжаты автоматты түрде жасалады. Бағдарламада штаттық кестені индекстеу автоматты түрде қызметкерлердің жалақысын индексациялауға әкелмейді және орташа жалақыны есептеуге әсер етпейді.

Қызметкерлердің тарифтік ставкаларының ағымдағы тарифтерін индекстеу

1С: Жалақы және персоналды басқару 8 бағдарламасының 3.1.3 нұсқасынан бастап, 3-шығарылым, қызметкерлердің тарифтік ставкаларының ағымдағы тарифтерін индекстеу тек тарифтік мөлшерлеменің өсуімен көрсетілмейді, бірақ басқа да өзгерістермен біріктірілуі мүмкін. жалпы тарифтік мөлшерлеменің құрамын анықтайтын алымдар. Бұл ретте индекстеу коэффициенті көрсетілмейді, бірақ жаңа жиынтық тарифтік мөлшерлеменің бұрынғыға қатынасы ретінде есептеледі. Қызметкерлердің тарифтік ставкаларының ағымдағы тарифтерін индекстеу Жоспарланған есептеулерді өзгерту құжаты арқылы жүзеге асырылады (мәзір Жалақы - Қызметкерлердің жалақысын өзгерту - Құру түймесі).

Тарифтік мөлшерлемелердің көтерілуін жүйе индекстеу ретінде қабылдауы үшін, яғни орташа табысты есептеу үшін өсу коэффициентін көрсету үшін «Жоспарланған есептеулерді өзгерту» құжатында Табысты индекстеу ретінде қарастыру жалаушасын орнату керек (Cурет 2). 2).

Бұл жалау, егер қызметкерлердің табыстары индекстелетін жалау арқылы жалақыны индекстеу тетіктерін пайдалану мүмкіндігі қосылған болса, құжатта қолжетімді (мәзір Параметрлер - Жалақы). «Таңдау» немесе «Толтыру» түймелерін пайдаланып, кірістері индекстелетін қызметкерлердің тізімін жасау керек. Әрі қарай, «Қызметкерлердің жалақысын өзгерту» құжатындағы «Индикаторларды толтыру» түймесін басу тұрақты мәндерді енгізуге болатын терезені ашады (Белгіленген мән - 2-суретті қараңыз) немесе математикалық операцияларды қолдана отырып, алдын ала толтырылғандарды қайта есептеуге (қосу, көбейту) , мысалы, Жалақыны, Сағаттық мөлшерлемені немесе жалпы тарифтік мөлшерлеменің құрамын анықтайтын басқа көрсеткішті көбейту керек коэффициентті көрсетеді. Қызметкерлердің жалақысын индекстеу туралы бұйрықтың басып шығарылған нысанын жасау үшін Табысты индекстеу туралы бұйрық түймесін басыңыз.

Егер кәсіпорын тарифтік топтарды пайдаланатын болса, онда Жоспарлы төлемдерді өзгерту құжатын Тарифтік топты бекіту құжатындағы Жоспарланған төлемдерді өзгерту түймешігін басу арқылы жасауға болады (меню Жалақы - Тарифтік топты бекіту).

немесе

Неліктен 1С әзірлеушісі өлшемдер мен мәліметтерді тіркеуді «индекстеу» керек?

- Жарайды, өтініштерің бар! – деді база іліп қойды...

Тақырыптық сұраққа қысқа жауап мынада: бұл сұрауларды жылдам орындауға мүмкіндік береді және құлыптардың теріс әсерін азайтады.

Индекс дегеніміз не?

Индексті орналастыруды оңтайландыру

Кестелердің көлемі оларды сервердің жедел жадына «сәйкестендіруге» мүмкіндік бермесе, дискінің ішкі жүйесінің жылдамдығы (енгізу/шығару) бірінші орынға шығады. Мұнда индекстерді әртүрлі қатты дискілерде орналасқан бөлек файлдарға орналастыру мүмкіндігіне назар аударуға болады.

Әрекеттердің толық сипаттамасы http://technet.microsoft.com/ru-ru/кітапхана/Ханым175905.aspx
Басқа файл тобынан индексті пайдалану енгізу/шығару процестерінің және индекстің өзінде жұмыс істеудің параллельділігіне байланысты кластерленбеген индекстердің өнімділігін жақсартады.
Өлшемдерді анықтау үшін жоғарыда аталған өңдеуді қолдануға болады.

Индекстердің құлыптарға әсері

Сұрау үшін қажетті индекстің болмауы кестенің барлық жазбалары арқылы итерациялауды білдіреді, бұл өз кезегінде артық құлыптарға әкеледі, яғни. қажет емес жазбалар бұғатталған. Оған қоса, индекстердің болмауына байланысты сұрауды аяқтау үшін неғұрлым ұзақ уақыт қажет болса, соғұрлым құлыпты ұстау уақыты ұзағырақ болады.
Құлыптардың тағы бір себебі - кестелердегі жазбалардың аздығы. Осыған байланысты, SQL Server сұранысты орындау жоспарын таңдағанда, индекстерді пайдаланбайды, бірақ бүкіл кестені блоктай отырып, бүкіл кестені тексереді (Кестені сканерлеу). Мұндай бұғаттауды болдырмау үшін кестелердегі жазбалар санын 1500-2000-ға дейін көбейту керек. Бұл жағдайда кестені сканерлеу қымбаттайды және SQL Server индекстерді пайдалана бастайды. Әрине, бұл әрқашан мүмкін емес бірқатар анықтамалықтар, мысалы, «Ұйымдар», «Қоймалар», «Бөлімшелер» т.б. әдетте жазбалар аз болады. Мұндай жағдайларда индекстеу өнімділікті жақсартпайды.

Көрсеткіш өнімділігі

Біз мақаланың атауында индекстердің сұрау өнімділігіне әсері қызықтыратынын атап өттік. Сонымен, индекстер келесі тапсырмалар түріне ең қолайлы:

• «Тар» іздеу шарттарын көрсететін сұраулар.Мұндай сұраулар белгілі бір критерийлерге сәйкес келетін жолдардың аз ғана санын оқуы керек.
• Мәндер ауқымын көрсететін сұраулар.Бұл сұраулар сонымен қатар аздаған жолдарды оқуы керек.
• Байланыстыру операцияларында қолданылатын іздеу.Жиі байланыстыру кілттері ретінде пайдаланылатын бағандар индекстер үшін тамаша.
• Деректер белгілі бір ретпен оқылатын іздеу.Нәтижелер жинағы кластерленген индекс ретімен сұрыпталатын болса, нәтижелер жинағы алдын ала сұрыпталғандықтан, сұрыптау қажет емес. Мысалы, тегі, аты бағандарда кластерленген индекс жасалса және қолданба тегі бойынша, содан кейін аты бойынша сұрыптауды қажет етсе, ТАПСЫРЫС БОЙЫНША сөйлемді қосудың қажеті жоқ.

Рас, индекстердің барлық пайдалылығымен бірге өте маңызды БІРАҚ бар – индекс «тиімді пайдаланылуы» керек және деректерді енгізу/шығару операцияларының аздығы мен жүйе ресурстарының көлемін пайдаланып табуға мүмкіндік беруі керек. Керісінше, пайдаланылмаған (сирек қолданылатын) индекстер деректерді жазу өнімділігін төмендету ықтималдығы жоғары (себебі деректерді өзгертетін әрбір операция индекс беттерін де жаңартуы керек) және артық дерекқор кеңістігін жасайды.

Қаптау(берілген сұрау үшін) осы сұранысқа барлық қажетті өрістерді қамтитын индекс деп аталады. Мысалы, егер индекс a, b және c бағандарында жасалса және SELECT мәлімдемесі деректерді тек сол бағандардан сұраса, онда индекске кіру ғана қажет.

Индекстің тиімділігін анықтау үшін біз «сұрауды орындау жоспарын» және пайдаланылған индекстерді көрсететін ақысыз онлайн қызметін пайдаланып шамамен бағалауға болады.