ჯგუფში ყოფნა 1C 8 იერარქიის მიხედვით. ოპერატორი „იერარქიაში“ მოთხოვნაში. ელემენტის ყველა მშობლის მიღება

12.12.2023სათაური: Უსაფრთხოება

ილდაროვიჩი 6489 16.11.12 18:24 ამჟამად თემაზე

() ვლადიმერ! მოხარული ვარ, რომ ყურადღება მიაქციეთ სტატიას, მით უმეტეს, რომ თქვენ ერთ-ერთი პირველი იყავით, ვინც დაინახა (და დააფასა) ეს ტექნიკა ორი წლის წინ დისკუსიაში „რეალურია რთული შეკითხვის დაწერა“. მე თვითონ არ დამებადა საინტერესო კითხვა, მაგრამ ვნახე ფორუმზე. კითხვის ავტორი სტანისლავ შეპტალოვია. შემდეგი - 10/24/12 იგივე (უბრალოდ შენიშნა ეს, რადგან მეტსახელი განსხვავებულია) ფორუმის მონაწილემ დაუსვა მსგავსი შეკითხვა, მაგრამ იერარქიაში განაცხადისას. გამოდის, რომ პრაქტიკული საკითხი მოგვარებულია. გარდა ამისა, "მეცნიერული" მიდგომის შესაბამისად, მე განვიხილე პრაქტიკული პრობლემები, სადაც ეს ტექნიკა შეიძლება გამოყენებულ იქნას. ნაპოვნია კიდევ 7 პრობლემა. 5 - ამ სტატიაში. მათ შორის არის პრობლემა სპეციფიკაციების ციკლებთან დაკავშირებით, რომელსაც ადრე დავპირდი, რომ გადავჭრი Ish_2 ერთი შეკითხვით. ვფიქრობ, Ish_2 შეძლებს დაგარწმუნოთ ამ ამოცანის აქტუალურობაში - მან დიდი დრო დახარჯა მასზე. გამოსავალი მოკლეა - რამდენიმე სტრიქონი, ამიტომ უკიდურესად მკაფიო, ჩამოყალიბებული არაპროცედურული სტილით, შედეგის მოთხოვნის მეშვეობით. ისე, სტატიებსა და ფორუმზე სხვა პრობლემები შეგვხვდა და მათთვის უფრო რთული გადაწყვეტილებები იყო შემოთავაზებული. მოდით დაველოდოთ ცოტა ხანს, რომ ვნახოთ რამდენად ხშირად იქნება ეს გამოყენებული. სწორედ ასეთ გამოხმაურებას ველოდები – მათგან, ვინც ეცდება.
სხვათა შორის, ის ფაქტი, რომ მათემატიკის ეს ფილიალი პრაქტიკისგან არც თუ ისე შორს არის და ბუღალტერებს სჭირდებათ, მოწმობს ზოგადი მოდული "ღირებულების რეგულირება" BP2-ში, რომელსაც ჩვენ ამჟამად ვახდენთ (სტანდარტული მოთხოვნის არასტაბილური მოქმედება). აქ ჩვენ ვსაუბრობთ ნივთების მოძრაობის გრაფიკის ციკლების გაწყვეტაზე და გაშლილი ხის აგებაზე.
ახლა მონაცემთა ბაზის სტრუქტურის შესახებ "კონკრეტული ამოცანისთვის". დაისვა კითხვა 1C-ში დავალების შესრულების შესახებ და, შესაბამისად, ამოცანა გადაწყდა 1C-ში. რომ გეკითხათ "რომელი ავტობუსით შეგიძლიათ წახვიდეთ ბიბლიოთეკაში" და თქვენ უპასუხეთ, რომ ჯობია დირიჟამზე ფრენა, მაშინ უბრალოდ ვერ გაგიგებთ (შესაძლოა, მათ გარდა, ვინც მოსკოვის საცობშია ჩარჩენილი. ). თავდაპირველად მეთოდი სრულიად განსხვავებულ ენაზე მუშაობდა.
ზოგადად, მე ვერ დაგარწმუნებთ, თუ ფიქრობთ, რომ 1C პლატფორმის არქიტექტურა არ არის კარგი. მე შემიძლია მხოლოდ ჩემი აზრი გამოვთქვა. მონაცემთა ბაზის სქემის შემუშავება ნულიდან კონკრეტული ამოცანისთვის ძვირია. თუ შევადარებთ მშენებლობას: 1C არის პანელის მაღალსართულიანი შენობები - იაფი საცხოვრებელი - მასობრივი ავტომატიზაციის საშუალება - დაძაბულ პირობებში, მაგრამ არა შეურაცხყოფა. ცალკეულ ორგანიზაციებს შეუძლიათ დაიქირაონ ნორმან ფოსტერი მათი მოთხოვნების ზუსტად განსახორციელებლად. დანარჩენებმა უნდა გამოიყენონ იაფი მასობრივი წარმოების პროექტები - რელაციური DBMS ხისტი ობიექტის მოდელით. გარდა ამისა, მე ვიცნობ ქეშის გამოყენების სამწუხარო გამოცდილებას რამდენიმე პროექტში. დეველოპერის თვალთახედვით, ყველაფერი ისე არ გამოიყურება, როგორც თეორიულად. 1C ობიექტის მოდელი უძლებს დროის გამოცდას - ”დიდი ტერიტორიები აშენებულია და დასახლებულია”. უფრო მეტიც, ის ვითარდება. ცოტა ხნის წინ გამოჩნდა გარე მონაცემთა წყაროების ტექნოლოგია. და თუ რომელიმე დავალება მოითხოვს უფრო მაღალ რეაქტიულობას (მაგალითად, ბილინგის სისტემები), ახლა შეგიძლიათ შეუფერხებლად დააკავშიროთ 1C სხვა DBMS-თან. მაგალითად, ასე ვცვლით იმპორტირებულ ERP-ს.
მაგრამ მაინც არ მსურს საუბრის გადატანა მთავარი თემიდან - შემოთავაზებული ტექნიკის მუშაობა დეტალურ პრაქტიკულ ამოცანებში.

რა არის 1C დირექტორია და რატომ არის საჭირო? დირექტორია ინახავს პირობითად მუდმივ ინფორმაციას, ე.ი. ინფორმაცია, რომელიც თითქმის უცვლელი რჩება დიდი ხნის განმავლობაში. მაგალითად, "ნომენკლატურის" დირექტორია შეიცავს გაყიდული ან წარმოებული საქონლის ჩამონათვალს. ასევე, დირექტორია შეიძლება შეიცავდეს მრავალ თვისებას, რომელიც აღწერს დირექტორიას ელემენტს.

თუ შედარებისთვის ავიღებთ პიროვნების სქესს, მაშინ სია შეზღუდულია და არ იცვლება, ამიტომ ჩამოთვლა უფრო შეეფერება მას.

ახალი დირექტორიას შექმნის შემდეგ, ჩვენ ვნახავთ შემდეგ სურათს.

მოდით გადავხედოთ მის ყველა სანიშნეს.

ძირითადი

აქ მითითებულია სახელი (იდენტიფიკატორი მონაცემთა ბაზაში) და სინონიმი (საქაღალდის მომხმარებლის სახელი). არასავალდებულო კომენტარი არის ის, რომელსაც შეუძლია ახსნას დირექტორიის მიზანი ან აღწეროს მისი მახასიათებლები.

იერარქია

ამ ჩანართზე შეგიძლიათ დააკონფიგურიროთ დირექტორია ელემენტების ბუდობის სიღრმე. ამ პარამეტრის გამოყენებით, მოსახერხებელია ელემენტების დიფერენცირება და დეტალიზაცია ზოგიერთი კრიტერიუმის მიხედვით. მაგალითად, პროდუქტები "კარადები" ერთ ჯგუფშია, ხოლო პროდუქტები "მაგიდები" მეორეში. ნაგულისხმევად, შექმნისას, დირექტორია არის წარმოდგენილი ელემენტების სია. თუ მონიშნეთ იერარქიული დირექტორიაში ჩამრთველი, მაშინ თითოეული ელემენტი შეიძლება დაექვემდებაროს სხვა ელემენტს (ჯგუფს). ქვემოთ მოცემულია ამ სანიშნის მორგების და მორგებულ რეჟიმში ეკრანის შეცვლის ვარიანტები.

იერარქიის ტიპი:

ჯგუფებისა და ელემენტების იერარქია

ამ პარამეტრით, ელემენტები შეიძლება იყოს ჩასმული მხოლოდ ჯგუფებში (საქაღალდეებში).

აქ, როგორც ხედავთ, ყველა ელემენტს და ჯგუფს აქვს ერთი და იგივე ხატები და ნებისმიერი ელემენტის ჩადგმა შესაძლებელია.

მოათავსეთ ჯგუფები თავზე

როდესაც ეს მონიშნული ველი მონიშნულია, ჯგუფები ყოველთვის იქნება ზედა, წინააღმდეგ შემთხვევაში ისინი დალაგდებიან დალაგების მიხედვით, მაგალითად, ასე:

იერარქიის დონეების რაოდენობის შეზღუდვა

თუ ჩამრთველი აქ არ არის მონიშნული, მაშინ ბუდე შეუზღუდავია.

თუ მონიშნული ველი არის მონიშნული, შეგიძლიათ ქვემოთ მიუთითოთ დონეების რაოდენობა.

მფლობელები

სანიშნეზე მფლობელები შეიძლება მიეთითოს სხვა დირექტორიები, რომელთა მიმართაც ეს არის დაქვემდებარებული. დაქვემდებარებული დირექტორიების ურთიერთობის დიაგრამა მსგავსია იერარქიული დირექტორიის ურთიერთობის დიაგრამასთან, მხოლოდ აქ სხვა დირექტორია მოქმედებს როგორც მშობელი და ეწოდება მფლობელს. ტიპიურ კონფიგურაციებში კარგი მაგალითია "Agreements" დირექტორიას დაქვემდებარება "Counterparties" დირექტორიასთან, რადგან არ შეიძლება არსებობდეს ხელშეკრულება, რომელიც არ ეკუთვნის რომელიმე კონტრაგენტს.

ველში „დირექტორიის მფლობელთა სია“ მიუთითებს იმ დირექტორიების სიას, რომლებიც ფლობენ ამ დირექტორიაში არსებულ ელემენტებს.

ქვემოთ ველში “Use of Subordination” მითითებულია, თუ რას დაექვემდებარება ამ დირექტორიას ელემენტები.

როგორ გავარკვიოთ პროგრამულად არის თუ არა დირექტორია იერარქიული

ამისათვის თქვენ უნდა მიმართოთ მეტამონაცემებს

ეს არის HierarchicalDirectory = Metadata.Directories.Counterparties.Hierarchical;

Გაგრძელება იქნება...

1C დირექტორიები არის სპეციალიზებული მეტამონაცემების ხის ობიექტი, რომელიც ემსახურება სტატიკური საცნობარო ინფორმაციის შენახვას. მაგალითად, ტიპურ კონფიგურაციებში შეგიძლიათ იხილოთ შემდეგი ხედები: , ნომენკლატურა, თანამშრომლები, ძირითადი საშუალებები და ა.შ. დირექტორიებში ინფორმაცია, როგორც წესი, ხშირად არ იცვლება. დირექტორიები შემდგომში გამოიყენება თითქმის ყველა სააღრიცხვო ობიექტში, როგორც სააღრიცხვო განყოფილება ან საცნობარო ინფორმაცია.

ქვემოთ განვიხილავთ კონფიგურატორიდან დირექტორიის დაყენებას და დიზაინს, მაგალითად, "ნომენკლატურის" დირექტორია.

ძირითადი ჩანართი

"ძირითადი" ჩანართში მითითებულია სახელი, სინონიმი, ობიექტის წარმოდგენა და დანიშნულების აღწერა.

ჩანართი "დირექტორიის იერარქია".

აქ ჩამოყალიბებულია დირექტორიას იერარქია.

იერარქია 1C 8.3-ში არის ორი ტიპის - ” ჯგუფები და ელემენტები"და" ელემენტები". ის განსხვავდება იმით, რომ პირველ შემთხვევაში მხოლოდ საქაღალდე (ჯგუფი) შეიძლება იყოს მშობელი (საქაღალდე), ხოლო მეორე შემთხვევაში ელემენტი ასევე შეიძლება იყოს მშობელი.

„დაათავსეთ ჯგუფები თავზე“ - დროშა პასუხისმგებელია ჯგუფების სიის სახით ჩვენებაზე.

ასევე პარამეტრებში შეგიძლიათ შეზღუდოთ ჯგუფების რაოდენობა დირექტორიაში იერარქიაში შესაბამისი პარამეტრის გამოყენებით.

მფლობელების ჩანართი

დირექტორია შეიძლება დაექვემდებაროს სხვა დირექტორიას. 1C 8.3-ის კონფიგურაციის თვალსაზრისით, ეს ნიშნავს, რომ "მფლობელი" ატრიბუტი სავალდებულო ხდება დაქვემდებარებული ელემენტისთვის. სტანდარტული კონფიგურაციების დირექტორიებს შორის ასეთი კავშირის მაგალითი "ნომენკლატურა - საზომი ერთეულები", "კონტრაქტორები - კონტრაქტორების ხელშეკრულებები".

დირექტორიას მფლობელი ასევე შეიძლება იყოს შემდეგი მეტამონაცემების ობიექტები: , .

მონაცემთა ჩანართი

მიიღეთ 267 ვიდეო გაკვეთილი 1C-ზე უფასოდ:

პროგრამისტის თვალსაზრისით ყველაზე მნიშვნელოვანი ჩანართი. ის შეიცავს დირექტორიას დეტალებს.

დირექტორიას აქვს სტანდარტული დეტალების ნაკრები, რომლებიც არ არის რედაქტირებული 1C 8.2 პროგრამისტის მიერ; მათი სია შეგიძლიათ ნახოთ ღილაკზე "სტანდარტული დეტალების" დაჭერით:

თითოეულზე უფრო დეტალურად ვისაუბრებ:

ეს ჯგუფი- ატრიბუტი ლოგიკური ტიპით, რომელიც მიუთითებს ჯგუფია თუ ელემენტი. ხელმისაწვდომია მხოლოდ იერარქიულ დირექტორიაში. Შენიშვნა, ამ ატრიბუტის მნიშვნელობა არ შეიძლება შეიცვალოს 1C: Enterprise რეჟიმში.
კოდი— რეკვიზიტები, აკრიფეთ ნომერი ან სტრიქონი (ჩვეულებრივ სტრიქონი). სისტემის მიერ ავტომატურად მინიჭებული ნომერი. ჩვეულებრივ გამოითვლება როგორც (წინა კოდი + 1). გირჩევთ გამოიყენოთ სტრიქონის ტიპი, რადგან რიცხვითი მნიშვნელობების დახარისხება არ მუშაობს ისე, როგორც მოსალოდნელია. შეიძლება გამოყენებულ იქნას როგორც დირექტორია პრეზენტაცია სიაში და შეყვანის ველებში. ჩვეულებრივ გამოიყენება ელემენტის მოსაძებნად სტრიქონში შესვლისას. თუ გჭირდებათ კოდის ველის ამოღება, ჩაწერეთ ნული სტრიქონის სიგრძეში.
სახელი- სავალდებულო დეტალები, სტრიქონის ტიპი. ხაზის მაქსიმალური სიგრძეა 150 სიმბოლო. შეიძლება გამოყენებულ იქნას როგორც დირექტორია პრეზენტაცია სიაში და შეყვანის ველებში. ჩვეულებრივ გამოიყენება ელემენტის მოსაძებნად სტრიქონში შესვლისას. თუ თქვენ გჭირდებათ სახელის ველის ამოღება, ჩაწერეთ ნული სტრიქონის სიგრძეში.
მშობელი- DirectoryLink ტიპის ატრიბუტი.<ИмяТекущегоСправочника>. ხელმისაწვდომია მხოლოდ იერარქიულ დირექტორიაში. მიუთითებს იერარქიაში ზემდგომ მშობელზე. თუ ელემენტი ან ჯგუფი არის დირექტორიაში, მაშინ მითითებულია მნიშვნელობა Directory.<ИмяТекущегоСправочника>.EmptyLink.
მფლობელი— ბმული მიმდინარე დირექტორიაში ელემენტის (ჯგუფის) მფლობელის ელემენტთან. ხელმისაწვდომია მხოლოდ დაქვემდებარებულ 1C დირექტორიაში.
დროშის წაშლა- რეკვიზიტები ლოგიკური ტიპის. პასუხისმგებელია სისტემაში „წაშლის ნიშნის“ ჩვენებაზე. წაშლისთვის მონიშნული ელემენტი ითვლება გამოუსადეგრად, მაგრამ ძველი დოკუმენტის მოძრაობა შეიძლება დარჩეს მასზე.
Ბმული- სტრიქონის ტიპის ველი. ეს ატრიბუტი ინახავს უნიკალურ ობიექტის იდენტიფიკატორს - GUID. ის, რასაც სისტემაში ვხედავთ ვიზუალურ ჩვენებაზე, სახელწოდებით „ბმული“, არის მხოლოდ ობიექტის წარმოდგენა. არ შეიძლება შეიცვალოს.
წინასწარ განსაზღვრული— ლოგიკური ტიპი, აჩვენებს არის თუ არა ელემენტი წინასწარ განსაზღვრული, ამაზე მოგვიანებით. არ შეიძლება შეიცვალოს.

ჩანართი „მონაცემები“ ასევე მიუთითებს დირექტორიაში სისტემაში; 8.2.16 ვერსიამდე წარმომადგენლობა შეიძლება იყოს მხოლოდ კოდი ან სახელი. პლატფორმის ბოლო ვერსიებში (დაწყებული 8.3-დან), ხედი შეიძლება დამოუკიდებლად იყოს აღწერილი მენეჯერის მოდულში "ViewReceivingProcessing" დამმუშავებლის გამოყენებით.

ნუმერაციის ჩანართი

აქ შეგიძლიათ მიუთითოთ დირექტორიის პარამეტრები ნუმერაციის შესახებ. რეკომენდებულია ავტონომერაციის გამოყენება. უნიკალურობის კონტროლი არის დროშა, რომელიც ეხმარება, საჭიროების შემთხვევაში, კოდის უნიკალური გახდეს. თუ დროშის დაყენებით ცდილობთ დაწეროთ დირექტორია ელემენტი არაუნიკალური კოდით, 1C-ში მიიღებთ შეტყობინებას "საქაღალდის კოდი გახდა არაუნიკალური".

კოდის სერია - განსაზღვრავს, თუ როგორ უნდა დანომროთ დირექტორია; შეგიძლიათ შეიყვანოთ დირექტორიას ნუმერაცია მფლობელის მიხედვით. მაგალითად, კონტრაქტორს "რქები და ჩლიქები" ექნება კონტრაქტების საკუთარი ნუმერაცია - "1, 2, 3" და ა.შ.

ფორმების ჩანართი

დირექტორიას ფორმები აღწერილია აქ. თუ კონფიგურაცია გაშვებულია როგორც ნორმალურ, ისე მართულ რეჟიმში, მაშინ ნაგულისხმევად იქნება ორი ჩანართი ფორმებით: „მთავარი“ და „მოწინავე“ - განსხვავებული ნორმალური და მართული აპლიკაციებისთვის.

ამ გვერდს აქვს დირექტორიაში მნიშვნელოვანი ფუნქცია - „“. ეს არის 1C 8-ის ძალიან მოსახერხებელი ფუნქცია, რომელიც საშუალებას გაძლევთ, შეყვანის ველში მონაცემების შევსებისას, არ შეხვიდეთ დირექტორიაში, არამედ აკრიფოთ მისი სახელი, კოდი და ა.შ. და აირჩიეთ სასურველი ელემენტი ჩამოსაშლელი სიიდან. ეს ასე გამოიყურება:

სხვა ჩანართი

ჩანართზე შეგიძლიათ მიიღოთ სწრაფი წვდომა დირექტორიის მთავარ მოდულებზე - ობიექტის მოდულზე და მენეჯერის მოდულზე.

ასევე შეგიძლიათ გვერდზე განსაზღვროთ წინასწარ განსაზღვრული დირექტორია ელემენტების სია. ეს არის ელემენტები, რომელთა წაშლა შეუძლებელია Enterprise Mode-ში. წინასწარ განსაზღვრულ ელემენტებზე წვდომა შესაძლებელია პირდაპირ კონფიგურატორში სახელით, მაგალითად: Directories.Nomenclature.Service.

ეს ჩანართი ასევე განსაზღვრავს დაბლოკვის რეჟიმს - ავტომატური ან კონტროლირებადი. სრული ტექსტის ძიების გამოყენება, ისევე როგორც საცნობარო ინფორმაცია დირექტორიაზე, ხელმისაწვდომია 1C: Enterprise რეჟიმში.

დიზაინი "IN HIERARCHY" 1C:Enterprise 8.x შეკითხვებში საშუალებას გაძლევთ მიიღოთ იერარქიული კონფიგურაციის ობიექტის დაქვემდებარებული ელემენტები მოცემული შერჩევის მიხედვით. დღეს სტატიაში განვიხილავთ მისი გამოყენების მაგალითს, ასევე პლატფორმის მოქმედებებს DBMS მხარეს და მის გავლენას შესრულებაზე.

გამოყენება

მოდით შევხედოთ "IN HIERARCHY" კონსტრუქციის გამოყენების მარტივ მაგალითს. შემდეგი მოთხოვნის შესრულებისას მიიღება იერარქიული დირექტორია „Products“-ის დაქვემდებარებული ელემენტები „Link“ ცვლადის გავლილი მნიშვნელობისთვის.

ტესტის მონაცემთა ბაზაში, "პროდუქტები" დირექტორიაში არის შემდეგი ტესტის მონაცემები:

რა თქმა უნდა, სურათი არ აჩვენებს დირექტორიაში ყველა ჩანაწერს. სკრინშოტი აჩვენებს მხოლოდ მონაცემთა შენახვის სტრუქტურას იერარქიულ დირექტორიაში. კატალოგის ცხრილი ინახავს 10 ზედა დონის ჯგუფს, რომელთაგან თითოეული შეიცავს 5 ჩადგმულ ჯგუფს 200 ელემენტით.

დავუბრუნდეთ ტესტის მოთხოვნას. მოდით გადავიტანოთ ბმული ჯგუფის "Group - 1" პარამეტრზე "&Link" (იხილეთ ეკრანის სურათი ზემოთ). შემდეგ შეკითხვის შედეგი ასე გამოიყურება:

როგორც ვხედავთ, მოთხოვნამ დააბრუნა ბმული თავად ზედა ჯგუფში (გადასული როგორც პარამეტრი), ასევე ჩადგმული ჯგუფები მათში შემავალი ელემენტებით. ამრიგად, "IN HIERARCHY" კონსტრუქციის გამოყენება საშუალებას გაძლევთ მოხერხებულად მიიღოთ იერარქიულად დაქვემდებარებული მონაცემები.

1C: Enterprise შეკითხვის ენის სინტაქსი კლასიკური SQLრაღაც მხრივ ძალიან ჰგავს. მაგრამ გამოთქმისთვის "IN HIERARCHY" არ არის ანალოგი SQL შეკითხვის ენაში, როგორც, მაგალითად, პლატფორმის "B" შეკითხვის ენის გამოხატვისთვის არის მსგავსი SQL ოპერატორი "IN". აქედან გამომდინარე, საინტერესოა პლატფორმის მუშაობა DBMS-თან ამ ოპერატორის გამოყენებისას.

Სცენის მიღმა

მოდით დავიწყოთ. მაგალითად, ჩვენ გამოვიყენებთ ადრე დაწერილ მოთხოვნას "პროდუქტები" დირექტორიაში. ჩვენ გავაანალიზებთ პლატფორმის მოქმედებებს ორი სიტუაციისთვის:

ჩვენ გადავცემთ უმაღლესი დონის ჯგუფს "ჯგუფი 1", როგორც "&Link" პარამეტრი (როგორც ადრე გავაკეთეთ).
პარამეტრში ჩვენ გადავცემთ ბმულს ჯგუფთან "ჯგუფი 1 - 1", ჩასმული ზედა დონის ჯგუფში "ჯგუფი 1".

ახლა, იმისათვის. პირველ შემთხვევაში, პლატფორმა შეასრულებს შემდეგ მოქმედებებს SQL სერვერზე:

1. პირველ რიგში, SQL მოთხოვნა შესრულებულია, რათა მივიღოთ ბმული დირექტორია ჯგუფის პარამეტრად და ყველა დაქვემდებარებულ ჯგუფთან. შედეგი მოთავსებულია დროებით ცხრილში "#tt1".

2. მეორე ეტაპზე ერთი და იგივე მოთხოვნა სრულდება ორჯერ:

ეკრანის სურათი შეიცავს დეტალურ კომენტარებს SQL მოთხოვნის ტექსტზე. მოკლედ, შეკითხვა საშუალებას გაძლევთ აირჩიოთ დაქვემდებარებული ელემენტები ჯგუფებისთვის, რომლებიც მითითებულია დროებით ცხრილში. რჩება კითხვა: "რატომ არის მოთხოვნა შესრულებული ორჯერ?" პასუხი აქ მარტივია: პირველ რიგში, მოთხოვნა იღებს დაქვემდებარებულ ელემენტებს პირველი დონის ჯგუფებისთვის, რომლებიც უკვე შეიცავს დროებით ცხრილში (იხ. პუნქტი 1). შემდეგ მეორე მოთხოვნა იპოვის ქვეელემენტებს მეორე დონის ქვეჯგუფებისთვის. ვინაიდან იერარქიის მესამე დონეზე არცერთი დირექტორია ჯგუფი არ არის, ეს მოთხოვნა აღარ არის შესრულებული.

ჩვენს შემთხვევაში, მეორე მოთხოვნა დააბრუნებს ცარიელ შედეგს, რადგან არ არსებობს დაქვემდებარებული ელემენტები იერარქიის მე-3 დონეზე მდებარე ჩანაწერებისთვის (იქ ჯგუფები არ არის).

3. მოთხოვნის საბოლოო შედეგის მისაღებად, პლატფორმა წარმოქმნის შემდეგ SQL მოთხოვნას:

ამ კონკრეტული მოთხოვნის შედეგი შეიძლება შემდგომ დამუშავდეს ალგორითმებით პლატფორმის ჩაშენებულ ენაზე. ამრიგად, ჩანაწერები დროებით ცხრილში "#tt1" გამოიყენება შერჩევის მდგომარეობის დასაყენებლად საცნობარო ცხრილიდან "_Reference41".

4. ბოლო ეტაპზე 1C:Enterprise 8.x პლატფორმა შლის დროებით ცხრილს „#tt1“, რადგან ის აღარ იქნება გამოყენებული მომავალში.

ამით სრულდება "IN HIERARCHY" ოპერატორის შესრულების პროცესი.შეგახსენებთ, რომ მოქმედებების განხილული თანმიმდევრობა შესრულდა SQL სერვერზე, როდესაც ჩვენ გადავეცით ბმული ზედა დონის ჯგუფში "Group - 1" პლატფორმის მხარეს მოთხოვნის შესახებ. მაგრამ როგორ მოიქცევა პლატფორმა, თუ ჩვენ გადავცემთ ბმულს მეორე დონის ჯგუფში „Group - 1 - 1“, როგორც „&Link“ პარამეტრი? ყველაფერი ასე მოხდება, გარდა შემდეგი პუნქტისა: ზემოთ, პლატფორმის მიერ SQL მოთხოვნების შესრულების მეორე ეტაპზე, დაიწერა, რომ დაქვემდებარებული ელემენტების მისაღებად მოთხოვნა შესრულდა ორჯერ - დაქვემდებარებული ელემენტების მიღების შემთხვევაში ჯგუფი "ჯგუფი - 1 - 1" ეს ასე არ არის. მოთხოვნა შესრულდება მხოლოდ ერთხელ.

ფაქტია, რომ დაქვემდებარებული ელემენტების მოპოვების მოთხოვნების რაოდენობა დამოკიდებულია იერარქიის ჯგუფების რაოდენობაზე. სხვა სიტყვებით რომ ვთქვათ, თუ ელემენტის იერარქიის დონე შეიცავს მინიმუმ ერთ ჯგუფს, მაშინ მოთხოვნა მე-2 პუნქტიდან.

შესრულების გავლენა

ნებისმიერი ოპერატორის არასწორმა გამოყენებამ მოთხოვნაში შეიძლება გამოიწვიოს სისტემის არაოპტიმალური შესრულება. გამონაკლისი არ არის განხილული ოპერატორი „HIERARCHY“. ის სიფრთხილით უნდა იქნას გამოყენებული, რადგან ის მნიშვნელოვნად ართულებს მონაცემთა ბაზაში SQL მოთხოვნების შესრულების ალგორითმს და ამით ზრდის დატვირთვას DBMS სერვერზე.

ნება მომეცით მოგცეთ არაოპტიმალური შეკითხვის მაგალითი, რომელმაც შეიძლება გამოიწვიოს ზემოთ ნახსენები სამწუხარო შედეგები:

აირჩიეთ პროდუქტები. ბმული დირექტორიადან. პროდუქტები, როგორც პროდუქტები WHERE (პროდუქტები. ბმული HIERARCHY-ში (& Link) ან პროდუქტები. Link IN HIERARCHY (& Link1) OR Products. Link IN HIERARCHY (& Link2) )

როგორც თქვენ მიხვდით, მოთხოვნა გამოიწვევს მრავალი SQL მოთხოვნის გენერირებას, რაც გამოიწვევს საინფორმაციო სისტემის მუშაობის შემცირებას.

გამოიტანე დასკვნები!

დასკვნების გამოტანა თქვენზეა დამოკიდებული. ნება მომეცით უბრალოდ ვთქვა, რომ ოპერატორი „IN HIERARCHY“ გამოიყენება პლატფორმის მიერ მონაცემთა შემადგენლობის სისტემისთვის, როდესაც შერჩევის პირობები მოიცავს „IN GROUP“, „IN GROUP FROM THE LIST“ და სხვა. ვფიქრობ, არ არის საჭირო ახსნა, რომ არასწორი მანიპულაციებით მომხმარებლებს შეუძლიათ დააყენონ ძალიან რთული არჩევანი და რამდენჯერმე გაზარდონ დატვირთვა 1C სერვერზე და DBMS-ზე. მოდით შევცვალოთ პარამეტრები მხოლოდ გამოცდილი მომხმარებლებისთვის.

და რა თქმა უნდა, საკუთარი მექანიზმების დაწერისას ყურადღება მიაქციეთ ოპერატორს "IN HIERARCHY". ერთის მხრივ ძალიან მოსახერხებელია, მეორეს მხრივ საშიში.

ამ განყოფილებაში ნაჩვენებია ტიპიური პრობლემების გადაჭრის მაგალითები იერარქიულ დირექტორიებთან მუშაობისას.

იერარქიული დირექტორიას ელემენტების მიღება, რომლებიც ექვემდებარება მოცემულ ჯგუფს

იერარქიული დირექტორიას დაქვემდებარებული ელემენტების მისაღებად, შეკითხვის ენა უზრუნველყოფს IN HIERARCHY კონსტრუქციას. გამოყენების მაგალითი იერარქიაში:

არჩევა
ნომენკლატურა.კოდი,
ნომენკლატურა.შესყიდვის ფასი
FROM

ამ მაგალითში მიიღება &Group ჯგუფში მდებარე ნომენკლატურის კატალოგის ყველა ჩანაწერი, მათ შორის თავად, მისი დაქვემდებარებული ჯგუფები და დაქვემდებარებული ჯგუფების კუთვნილი ელემენტები.

თუ ჩვენ გვაინტერესებს მხოლოდ ელემენტები და ჯგუფები, რომლებიც მდებარეობს უშუალოდ მოცემულ ჯგუფში, მაშინ ასეთი ელემენტების მიღება შეგვიძლია მშობლის ველზე პირობის დაყენებით. მაგალითი:

არჩევა
ნომენკლატურა.კოდი,
სახელწოდება AS სახელი,
ნომენკლატურა.შესყიდვის ფასი
FROM
დირექტორია.Nomenclature AS Nomenclature

სად
ნომენკლატურა.მშობელი = &ჯგუფი

ეს მოთხოვნა შეარჩევს ჯგუფებს და ჯგუფს დაქვემდებარებულ ელემენტებს &ჯგუფის ბმულით.

დირექტორია ელემენტის დაქვემდებარებული ელემენტების არსებობის შემოწმება

დირექტორიის ელემენტის დაქვემდებარებული ჩანაწერების არსებობის შესამოწმებლად, შეგიძლიათ გამოიყენოთ მსგავსი მოთხოვნა:

ამ მაგალითში, მითითება ელემენტზე, რომლის შემოწმებაც გსურთ ბავშვებისთვის, ჩაწერილია მშობლის შეკითხვის პარამეტრზე. ასეთი მოთხოვნის შესრულების შემდეგ, თქვენ უნდა შეამოწმოთ შედეგი სიცარიელისთვის. თუ შედეგი ცარიელი არ არის, მაშინ არის დაქვემდებარებული ჩანაწერები. წინააღმდეგ შემთხვევაში - არა. მაგალითი:

If Request.Execute().Empty() მაშინ
ანგარიში ("ჩანაწერები არ არის");
წინააღმდეგ შემთხვევაში
ანგარიში ("ხელმისაწვდომი ჩანაწერები");
დაასრულე თუ;

ელემენტის ყველა მშობლის მიღება

შეკითხვის ენა არ იძლევა რაიმე განსაკუთრებულ საშუალებას ელემენტის ყველა მშობლის მოსაძიებლად. თქვენ შეგიძლიათ გამოიყენოთ იერარქიული ჯამები ამოცანის შესასრულებლად, მაგრამ იერარქიული ჯამების მიღება ოპტიმიზებულია დიდი რაოდენობის ჩანაწერებისთვის ჯამების შესაქმნელად და არ არის მთლად ეფექტური ერთი ელემენტის მშობლების მისაღებად. ელემენტის ყველა მშობლის ჩანაწერის უფრო ეფექტურად მოსაპოვებლად, რეკომენდებულია მისი მშობლების მცირე ნაწილებში გადატანა. მაგალითი:

CurrentItemItem = ItemItem;

ჭეშმარიტების ციკლის დროს
Request.SetParameter("CurrentItemItem", CurrentItemItem);
შედეგი = Query.Run();
თუ შედეგი.Empty() მაშინ
Გაუქმება;
დაასრულე თუ;
Selection = Result.Select();
Selection.Next();
ColumnNumber-ისთვის = 0 By Result.Columns.Quantity() - 1 ციკლი
CurrentItemItem = Selection[ColumnNumber];
Გაუქმება;
წინააღმდეგ შემთხვევაში
ანგარიში (CurrentItemItem);
დაასრულე თუ;
საბოლოო ციკლი;

თუ CurrentItemItem = Directories.Nomenclature.EmptyLink() მაშინ
Გაუქმება;
დაასრულე თუ;
საბოლოო ციკლი;

ამ მაგალითში, ElementNomenclature ცვლადში ჩაწერილი ბმულის ყველა მშობელი ნაჩვენებია სერვისის შეტყობინების ფანჯარაში. ციკლში არჩეულია 5 ბმული მშობელი.

თუ დირექტორიაში დონეების რაოდენობა შეზღუდულია და მცირეა, მაშინ შესაძლებელია ყველა მშობლის მიღება ერთი მოთხოვნით მარყუჟის გარეშე.

მოხსენებაში იერარქიული დირექტორიას ჩვენება

იერარქიული დირექტორია ანგარიშში იერარქიის შესანარჩუნებლად გამოსაჩენად, თქვენ უნდა გამოიყენოთ შემდეგი მოთხოვნა:

არჩევა
ნომენკლატურა.კოდი,
სახელწოდება AS სახელი,
ნომენკლატურა.შესყიდვის ფასი
FROM
დირექტორია.Nomenclature AS Nomenclature
ᲓᲐᲚᲐᲒᲔᲑᲐ
სახელი HIERARCHY

ეს შეკითხვა ირჩევს ყველა ჩანაწერს დირექტორიადან და აწყობს მათ იერარქიის მიხედვით. შედეგი დალაგდება სახელწოდებით, იერარქიის გათვალისწინებით.

იმისთვის, რომ დირექტორია ჯგუფები განთავსდეს ელემენტებზე ზემოთ, აუცილებელია ამ მოთხოვნაში ORDER BY პუნქტის შეცვლა შემდეგით:

ᲓᲐᲚᲐᲒᲔᲑᲐ
ნომენკლატურა.ეს არის ჯგუფის იერარქია,
სახელი

შედეგი მაინც დალაგდება იერარქიულად, მაგრამ ჯგუფები გამოჩნდება ელემენტების ზემოთ.

ასევე შესაძლებელია ORDER BY შეთავაზების შეცვლა AUTO ORDER ოფციით. ამ შემთხვევაში შედეგი შეკვეთილი იქნება დირექტორიის პარამეტრების შესაბამისად, ე.ი. თუ დირექტორიაში მითითებულია, რომ ჯგუფები უნდა განთავსდეს ელემენტების ზემოთ, მაშინ ისინი განთავსდება ზემოთ.

ასევე შესაძლებელია კატალოგის იერარქიული სტრუქტურის მიღება შედეგების გამოყენებით.

არჩევა
ნომენკლატურა.კოდი,
სახელწოდება AS სახელი,
ნომენკლატურა.შესყიდვის ფასი

FROM Directory.Nomenclature AS Nomenclature

სად
(ნომენკლატურა.ThisGroup = FALSE)

შეკვეთა სახელით

ჯამების მიღება იერარქიის მიხედვით

შეკითხვისას იერარქიის მიხედვით ჯამების მისაღებად, თქვენ უნდა მიუთითოთ საკვანძო სიტყვა HIERARCHY SOFTWARE TOTAL პუნქტში, ველის მითითების შემდეგ, რომლითაც გამოითვლება ჯამები. ანგარიშის მაგალითი "საქონელი ბრუნვა" ჯამების მოპოვებით იერარქიის მიხედვით:

არჩევა

FROM

ნომენკლატურა იერარქია

ამ მოთხოვნის შედეგად ჯამები გამოითვლება არა მხოლოდ თითოეული ნივთისთვის, არამედ იმ ჯგუფებისთვისაც, რომლებსაც ესა თუ ის ნივთი ეკუთვნის.

იმ შემთხვევაში, როდესაც ჩვენ არ გვჭირდება ჯამები ელემენტებისთვის, არამედ გვჭირდება მხოლოდ ჯამები ჯგუფებისთვის, ჩვენ უნდა გამოვიყენოთ HIERARCHY ONLY კონსტრუქცია ჯამებში. მაგალითი:

არჩევა
ნომენკლატურის აღრიცხვაბრუნვა.ნომენკლატურა AS ნომენკლატურა,
ნომენკლატურის აღრიცხვაბრუნვა.ნომენკლატურა.პრეზენტაცია,
ნომენკლატურის აღრიცხვა ბრუნვა.რაოდენობაბრუნვა როგორც რაოდენობაბრუნვა
FROM
დაგროვების რეესტრი.ნომენკლატური აღრიცხვა.ბრუნვა HOW ნომენკლატურა აღრიცხვაბრუნვა
შედეგების თანხა (რაოდენობრივი ბრუნვა) PO
ნომენკლატურა მხოლოდ იერარქია

ამ მოთხოვნის შედეგი იქნება მთლიანი ჩანაწერები მხოლოდ ერთეულების ჯგუფებისთვის.