ახალი ძიების ფუნქციონირება დაფუძნებულია ორ მექანიზმზე:
- სრული ტექსტის ძიება (მუშაობს ძალიან სწრაფად და მოითხოვს მინიმალურ გამოთვლით რესურსებს);
- ძიება DBMS-ის საშუალებით (ზოგად შემთხვევაში, ძიების ხანგრძლივობა და გამოთვლითი რესურსების ღირებულება პროპორციულია ცხრილში მოცემული ინფორმაციის მოცულობისა).
მიმდინარე განხორციელებისას, სია მოძებნილი იქნება გამოყენების გარეშესრული ტექსტის ძიება შემდეგ შემთხვევებში ():
- სრული ტექსტის ინდექსი გამორთულია საინფორმაციო ბაზის დონეზე;
- ძირითადი ცხრილის ობიექტი არ არის ინდექსირებული სრული ტექსტის ინდექსით;
- სრული ტექსტის ძიების გამოყენებით ძიების შედეგად მიღებული იქნა შეცდომა.
თუ სრული ტექსტის ძიება ჩართულია ინფობაზაში და ინდექსი არ არის განახლებული საერთოდ ან ნაწილობრივ (ჩემი პრაქტიკიდან გამომდინარე მომხმარებელთა საინფორმაციო ბაზების 95%), მაშინ მომხმარებელი მიიღებს ან არასანდო ან ცარიელ ძიების შედეგს ძიების დროს. .
ჩვენ ვეკითხებით ფირმა 1C - როგორ ვიყოთ? როგორ დავრწმუნდეთ, რომ ძიების შედეგები ყოველთვის სწორია?
ჩვენ ვიღებთ პასუხს: დიახ, იმისათვის, რომ ძიების შედეგები იყოს განახლებული, როდესაც ჩართულია სრული ტექსტის ძიება, თქვენ უნდა დარწმუნდეთ, რომ სრული ტექსტის ძიების ინდექსი განახლებულია. ეფექტური და განახლებული სხვა ვარიანტები არ არსებობს. დღემდე ძიება ჯერ
().
და არის თუ არა ზოგადად "ფაქტობრივი სრული ტექსტის ინდექსი"? დამოკიდებულია მომხმარებელთა რაოდენობაზე, მონაცემთა ბაზაში ინფორმაციის ცვლილებების ინტენსივობაზე და ინდექსის განახლების სიხშირეზე. როგორც წესი, ინდექსის განახლება ხდება ყოველ 60 წამში. ისე, თუ ბევრი ობიექტი არ შეიცვალა და პროცედურამ მოახერხა ყველა ცვლილების დამუშავება ამ 60 წამში. და თუ გააკეთეთ დოკუმენტების ჯგუფის ხელახალი გამოქვეყნება, ან კატალოგის მასობრივი გადაწერა? ამ შემთხვევაში, ვერავინ იძლევა გარანტიას იმ დროის შემდეგ, რის შემდეგაც ინდექსში ძიება კვლავ იძლევა სანდო მონაცემებს.
პრინციპში, ეს არ არის განსაკუთრებით კრიტიკული, გარდა რამდენიმე სიტუაციისა. მომხმარებლის მუშაობის საერთო ვარიანტია სიაში შერჩევის დაყენება გარკვეული მნიშვნელობით, მაგალითად, "კონტრაგედი", შეიტანეთ ახალი ან დააკოპირეთ არსებული დოკუმენტი და ჩაწერეთ იგი. ძველი ძიებით, ახალი დოკუმენტი მყისიერად გამოჩნდა სიაში. ახლა მომხმარებელი დაინახავს მას საუკეთესო შემთხვევაში მხოლოდ N წამის შემდეგ, სადაც N უფრო ახლოს არის 50-60 წამთან, ვიდრე 2-3.
თუ არ შეამჩნევთ, რომ ახალი დოკუმენტი არ არის და არჩეული შედეგების მიხედვით ვინმეს მიაწვდით ინფორმაციას, მაშინ ის აშკარად არასანდო იქნება.
ეს იყო ინფობაზთან ნორმალური მუშაობის შემთხვევაში. რა ხდება კონკრეტულ სიტუაციებში? რამდენიმე მაგალითს მოგიყვან.
1) სამუშაო მონაცემთა ბაზაში ჩართულია და ხშირად განახლდება სრული ტექსტის ინდექსი. მომხმარებელი ითხოვს სამუშაო მონაცემთა ბაზის ასლის განთავსებას მასზე, რათა მან შეძლოს მასზე არსებული მონაცემების ანალიზი.
ჩვენ აღვადგენთ სარეზერვო ასლს და ვაძლევთ წვდომას. მაგრამ სრული ტექსტის ძებნა არ იმუშავებს, რადგან. ინდექსი ინახება არა DBMS-ში, არამედ ცალკეულ ფაილებში (როგორც ფაილში, ასევე კლიენტ-სერვერის ვერსიაში). ინდექსი არ არის dt ფაილში.
იმათ. იმისათვის, რომ მომხმარებელმა შეძლოს სიის ძიების გამოყენება, ამ მონაცემთა ბაზაში სრული ტექსტის ინდექსი უნდა იყოს გამორთული. მართალია, მომხმარებელი ოდნავ გაოცდება, რომ ძებნას გაცილებით მეტი დრო დასჭირდება. ან აღადგინეთ ინდექსი მთელ მონაცემთა ბაზაში.
2) (აქტუალურია მეტ-ნაკლებად დიდი ბაზებისთვის). წარმოების მონაცემთა ბაზაში სრული ტექსტის ინდექსი ჩართულია და ხშირად განახლდება. მოდის თვის ბოლო და იწყება პერიოდის დახურვა. ჩვენ ვიწყებთ დოკუმენტების ნაყარი დატვირთვას და გადაცემას. სისტემაზე დატვირთვის შესამცირებლად, ჩვენ ვბლოკავთ დაგეგმილი ამოცანების შესრულებას, შესაბამისად და ინდექსის განახლება ჩერდება. მომხმარებლები, რბილად რომ ვთქვათ, ზარალდებიან - რატომ არ არის ახალი ან შეცვლილი დოკუმენტები სიებში. ერთადერთი გამოსავალი არის ინფორმაციის ბაზის სრული ტექსტის ძიების გამორთვა და, შესაბამისად, აღჭურვილობაზე კიდევ უფრო დიდი დატვირთვის მიღება ყველა დეტალის მძიმე ძიების გამო.
ამრიგად, მეჩვენება, რომ ინდექსის განახლების ოპერაცია კიდევ ერთი თავის ტკივილი გახდება ინფობაზის ადმინისტრატორებისთვის.
სისტემა, რომელიც ადრე გარანტირებული იყო ინფორმაციის 100%-იანი სიზუსტისა და შესაბამისობის შესახებ ნებისმიერ დროს, ახლა უფრო მეტად იქცევა საცნობარო სისტემად, რომელშიც ბოლომდე დარწმუნებული ვერ იქნება.
და მომხმარებლები იღებენ კიდევ ერთ მიზეზს IT ადამიანების საყვედურებისთვის - "თქვენი სისტემა არ მუშაობს გამართულად".
იმისდა მიუხედავად, რომ 8.3 პლატფორმაზე სრული ტექსტის ძებნა დეველოპერებმა დიდი ხნის წინ გამოაცხადეს (8.3.5 პლატფორმიდან მოყოლებული), ის აქტიურად არ გამოიყენებოდა სტანდარტულ კონფიგურაციებში. Enterprise Accounting 3.0-ის ბოლო გამოშვებებში, დეველოპერებმა შეიტანეს სრული ტექსტის ძიება მრავალ სიაში. ჩემი მომხმარებლებისთვის ეს შოკი აღმოჩნდა - პროგრამამ შეწყვიტა ძებნა.
რა თქმა უნდა, სრული ტექსტის ძებნა მუშაობს, მაგრამ მომხმარებლები, რომლებიც ვერ ხედავენ "ძებნის" ფანჯარას, დაბნეულები არიან. გამოყენების ტიპიური სცენარი: დაიწყეთ აკრეფა კლავიატურაზე, აკრეფისას ჩნდება ფანჯარა "Find", რომელიც მიუთითებს საძიებო ველზე, საძიებო ტექსტზე და ძიების რეჟიმზე "სტრიქონის ნაწილი".
შეყვანის ღილაკზე დაჭერით, სია იფილტრება, ძებნის სტატუსის ზოლი გამოჩნდება სიის ზემოთ. მომხმარებელი თავად განსაზღვრავს რომელ სფეროში და რას ეძებს. ახალი ძიება იწყებს მუშაობას, როგორც კი აკრიფებთ და გავლენას ახდენს სიაში გამოსახულ ყველა ველზე. ცალკე ფანჯარა არ გამოჩნდება, საძიებო სიტყვების ყველა შესატყვისი ფერით არის მონიშნული.
რამდენიმე დღე ვცხოვრობდით ახალი ძიებით. მომხმარებლები განიცდიდნენ, ჩიოდნენ, დივერსიას ახდენდნენ. ჩივილები არ წყდებოდა, ხელმძღვანელობას დაევალა „ყველაფერი ისე გაეკეთებინა, როგორც იყო“.
სად უნდა დაიწყოს? თქვენ უნდა გესმოდეთ, თუ როგორ განსხვავდება ფორმები ერთმანეთისგან. მე გადმოვწერე კონფიგურაციის წყაროს კოდები ახალი საძიებო ქცევით და ძველთან და შევადარე ფორმების საწყისი კოდები.
"Search string" ტიპის ფორმის ელემენტის დამატება პასუხისმგებელია ახალი სრული ტექსტის ძიების ფუნქციონირებაზე. ნათელი გახდა, რა უნდა ვეძებოთ. ნაპოვნია სტატია ITS 7.3.1.5-ზე. მოძებნეთ დინამიურ სიაში. ამ სტატიის შესწავლამ მიმიყვანა დასკვნამდე, რომ ძიების მუშაობის ახალი გზა დამოკიდებულია ორ ფაქტორზე: 1. ფორმას უნდა ჰქონდეს ზემოაღნიშნული ფორმის ელემენტის შევსება, 2. ფორმის დინამიურ სიას უნდა ჰქონდეს "SearchStringPosition" თვისება, რომელიც არ არის ტოლი. "არცერთი".
თეორიულად სერვერზე ფორმის შექმნისას საკმარისია "SearchString Position" list თვისება დააყენოთ "SearchString Position. No", მაგრამ ეს არ მუშაობდა ყველა ფორმასთან, ზოგიერთ შემთხვევაში ახალი ძიება განაგრძობდა მუშაობას. ჩვენ არ შეგვიძლია პროგრამულად წაშალოთ არაპროგრამულად შექმნილი ფორმის ელემენტები, მაგრამ ხილვადობა შეიძლება გაკონტროლდეს. თუ ფორმის ელემენტი "AdditionSearchString" ამოღებულია ხილვადობიდან, სრული ტექსტის ახალი ძიება ასევე შეწყვეტს მუშაობას. ექსპერიმენტების დროს დაიბადა შემდეგი კოდი, რომელიც განვათავსე ზოგად მოდულში:
NewSearchInLists(Form) Export List = Form.Items.Find("List"); თუ სია = განუსაზღვრელი, მაშინ დაბრუნება; Დაასრულე თუ; List.SearchStringPosition = SearchStringPosition.None; AdditionSearchString = Form.Elements.Find("AdditionSearchString"); თუ არა ComplementSearchString = განუსაზღვრელია, მაშინ ComplementSearchString.Visibility = False; Დაასრულე თუ; დასრულების პროცედურა
პროცედურაში "სიებში ახალი ძიების გამორთვა" თქვენ უნდა გაიაროთ შესწორებული ფორმა. მაგრამ როგორ შეიძლება ამის გაკეთება ყველა ფორმისთვის ერთდროულად?
პირველი გამოსავალი არის კონფიგურატორში საჭირო ფორმების ხელით დაფიქსირება ფორმის რედაქტორის გამოყენებით. მე მაშინვე უარი ვთქვი ამ გადაწყვეტილებაზე - ის გრძელი და მოსაწყენია და რთულია კონფიგურაციის მოგვიანებით განახლება.
მეორე გამოსავალი არის ფორმის გახსნისას პროცედურის გამოძახება, რომელიც პროგრამულად გამორთავს ახალ ძიებას. პროცედურა შეიძლება გამოიძახოს ნებისმიერი სხვა პროცედურიდან, რომლის გაშვება უკვე დარეგისტრირებულია ყველა ფორმით, ამ შემთხვევაში, შემდგომი განახლებით, დაგვჭირდება მხოლოდ ამ პროცედურის მონიტორინგი - რომ არ შეიცვალოს. მე ავირჩიე GeneralModule.ManagePrint, რომელსაც აქვს:
OnCreateOnServer(Form,DefaultCommandPlace,PrintObjects) ექსპორტი
ეს პროცედურა იწოდება, როდესაც ფორმა იქმნება სერვერზე ბეჭდვის ბრძანებების შესავსებად. ამ პროცედურაში ჩვენ ვწერთ კოდს, რომელიც მოუწოდებს ჩვენს ფუნქციას სიებში ახალი ძიების გამორთვისთვის:
MyGeneralModule.NewSearchInLists(ფორმის) გამორთვა;
ბუღალტერები სარგებლობენ ძველი ძიებით და ჩვენ ვემზადებით იმისთვის, რომ Enterprise Accounting 3.0-ის თავსებადობის რეჟიმი მოგვცემს ამ ფუნქციის გაფართოების პორტირებას.
აქამდე ცოტამ თუ იცის, რომ 8.1 ვერსიიდან დაწყებული, 1C:Enterprise პლატფორმას აქვს შესანიშნავი და ძალიან სასარგებლო მექანიზმი - სრული ტექსტის ძიება. რა არის ეს? როგორ შეიძლება ის თქვენთვის სასარგებლო იყოს? ამ კითხვებზე პასუხობს სტატიაში ვ.ვ. თევზაობა, ფირმა "1C".
პირველი, რამდენიმე სიტყვა იმის შესახებ, თუ რა სახის მექანიზმია ეს. სრული ტექსტის ძებნა, მარტივი სიტყვებით, საშუალებას მოგცემთ იპოვოთ ტექსტური ინფორმაცია გამოყენებული კონფიგურაციის თითქმის ნებისმიერ ადგილას. ამავდროულად, თქვენ შეგიძლიათ მოძებნოთ საჭირო მონაცემები ან მთლიანი კონფიგურაციის მასშტაბით, ან ძიების არეალის შევიწროებით რამდენიმე ობიექტზე (მაგალითად, გარკვეული ტიპის დოკუმენტები ან დირექტორიები). თავად ძიების კრიტერიუმები შეიძლება განსხვავდებოდეს საკმაოდ ფართო დიაპაზონში. ანუ, თქვენ შეგიძლიათ იპოვოთ საჭირო მონაცემები ისე, რომ არ გახსოვთ ზუსტად სად ინახება ისინი კონფიგურაციაში და ზუსტად როგორ არის ჩაწერილი.
სრული ტექსტის ძიება უზრუნველყოფს შემდეგ ფუნქციებს.
- არსებობს ტრანსლიტერაციის მხარდაჭერა (რუსული სიტყვების ლათინური ასოებით წერა GOST 7.79-2000 შესაბამისად). მაგალითი: "რუსული ფრაზა" = "რუსული ფრაზა".
- არსებობს ჩანაცვლების მხარდაჭერა (სიმბოლოების ნაწილის რუსული სიტყვებით დაწერა ერთი გასაღები ლათინური სიმბოლოებით). მაგალითი: "russrfz frapf" (თითოეული სიტყვის დაბოლოებები იბეჭდება ლათინურად, მაგალითად, ოპერატორის შეცდომის შედეგად).
- არსებობს ბუნდოვანი ძიების შესაძლებლობა (ნაპოვნი სიტყვების ასოები შეიძლება განსხვავდებოდეს) ბუნდოვანობის ზღურბლის მითითებით. მაგალითი: საძიებო სტრიქონში სიტყვის "გამარჯობა" და 17%-იანი ბუნდოვანის მითითებით ჩვენ ვიპოვით ყველა მსგავს სიტყვას შეცდომით და გარეშე: "გამარჯობა", "გამარჯობა", "მოიტანე".
- შესაძლებელია შერჩეული მეტამონაცემების ობიექტების ძიების ფარგლების დაზუსტება.
- სტანდარტული ველების სახელების სრული ტექსტური ინდექსირება ("კოდი", "აღწერა" და ა.შ.) შესრულებულია ყველა კონფიგურაციის ენაზე.
- ძიება ხორციელდება რუსული, ინგლისური და უკრაინული ენების სინონიმების გათვალისწინებით.
- რუსული ენის მორფოლოგიური ლექსიკონი შეიცავს უამრავ კონკრეტულ სიტყვას, რომლებიც დაკავშირებულია საქმიანობის სფეროებთან, რომლებიც ავტომატიზირებულია 1C: Enterprise პროგრამის სისტემის გამოყენებით.
- როგორც სტანდარტი, მოწოდებულ ლექსიკონებში შედის ლექსიკონის მონაცემთა ბაზები და ლექსიკონები თეზაურუსისა და რუსული, უკრაინული და სინონიმები. ინგლისურიგთავაზობთ Informatik-ს.
- შეგიძლიათ მოძებნოთ ველური სიმბოლოების ("*"), ასევე საძიებო ოპერატორების ("AND", "OR", "NOT", "NEAR") და სპეციალური სიმბოლოების მითითებით.
სრული ტექსტის ძიება შეიძლება განხორციელდეს ნებისმიერი კონფიგურაციით 1C:Enterprise 8.1 პლატფორმაზე.
ეს ასევე ეხება კონფიგურაციებს, რომლებიც გადაკეთებულია 8.0 ვერსიიდან. სრული ტექსტის ძიების შესაძლებლობების გასააქტიურებლად, უბრალოდ გადადით თქვენი კონფიგურაციის "ოპერაციების" მენიუში და აირჩიეთ პუნქტი "სრული ტექსტის ძიების მართვა" და შემდეგ ჩართეთ ეს ფუნქცია (იხ. სურ. 1).
ბრინჯი. ერთი
თუ იყენებთ ტიპურ კონფიგურაციებს 8.1 პლატფორმაზე, მაშინ, სავარაუდოდ, მათ უკვე აქვთ ჩაშენებული "მონაცემთა ძებნა" დამუშავება (მენიუ "ინსტრუმენტები" / "მონაცემთა ძებნა"). თუ ასეთი დამუშავება არ არის გამოყენებული კონფიგურაციაში, არ აქვს მნიშვნელობა.
ის ყოველთვის შეგიძლიათ იპოვოთ ITS დისკზე. ამ სტატიაში ჩვენ გამოვიყენებთ ამ კონკრეტული დამუშავების მუშაობის მაგალითებს დემო კონფიგურაციაში "Enterprise Accounting" (რედ. 1.6) სრული ტექსტის ძიების შესაძლებლობების დემონსტრირებისთვის.
როგორც უკვე აღვნიშნეთ, ძიება შეიძლება განხორციელდეს რამდენიმე სიტყვით, საძიებო ოპერატორების გამოყენებით და ზუსტი ფრაზით. გარდა ამისა, საძიებო მდებარეობა შეიძლება შემოიფარგლოს კონკრეტული კონფიგურაციის ობიექტებით (მაგ., Production Services Act დოკუმენტები) ან კონფიგურაციის ობიექტების სიით/კომპლექტით.
მონაცემთა ძიებისას ნებადართულია საძიებო ოპერატორების გამოყენება ცხრილში მითითებულ საძიებო სტრიქონში (ყველა ოპერატორი მითითებული უნდა იყოს მხოლოდ CAPITA ასოებით და ბრჭყალების გარეშე).
მაგიდა
გაითვალისწინეთ: თუ ოპერატორები არ არის მითითებული (სიტყვები იბეჭდება ინტერვალით), პროგრამა ეძებს ყველა სიტყვას მოთხოვნიდან "AND" ოპერატორის გამოყენებით.
ბრინჯი. 2 გვიჩვენებს მარტივი სიტყვის ნაწილის ძიების მაგალითს. "იმედი *" აკრეფით, შედეგად მივიღეთ ბმული ინდივიდუალური, ასევე დოკუმენტებზე, რომელთა კომენტარებში გვხვდება ფრაზა "სანდო კლიენტი".
ბრინჯი. 2
ბრინჯი. 3 გვიჩვენებს უფრო რთული ძიების მაგალითს საძიებო სტრიქონში "OR" კონსტრუქციის გამოყენებით და "ნომენკლატურის" დირექტორიაში საძიებო არეალის შეზღუდვით და დოკუმენტებით "საქონლისა და მომსახურების მიღება", "საქონლისა და მომსახურების გაყიდვა". ნათლად ჩანს, რომ ძიება ასახავდა მთელ ნომენკლატურას, რომლის სახელწოდებებში არის სიტყვა „ჩაიდანი“ ან სიტყვა „BINATONE“, ისევე როგორც ყველა ამ ტიპის დოკუმენტი, რომელიც შეიცავს ყველა შესაბამის ნომენკლატურას.
ყველა ბუღალტერმა არ იცის ამის შესახებ. სასარგებლო ინსტრუმენტი 1C-ში: ბუღალტერია 8, როგორც სრული ტექსტის ძიება. სრული ტექსტის ძიების მექანიზმი საშუალებას გაძლევთ იპოვოთ ტექსტური ინფორმაცია კონფიგურაციის ნებისმიერ ადგილას.
სრული ტექსტის ძიება ხორციელდება "მონაცემთა ძიების" დამუშავების გამოყენებით, რომელიც მდებარეობს "ინსტრუმენტები" მენიუში:
მოდით შევხედოთ რამდენიმე მაგალითს, თუ როგორ მუშაობს სრული ტექსტის ძიების მექანიზმი.
მაგალითი 1დავუშვათ, ჩვენ გვჭირდება სწრაფად მოვძებნოთ დოკუმენტები გარკვეული პროდუქტის მისაღებად, მაგალითად, Marlboro სიგარეტი.
აირჩიეთ "მონაცემთა ძებნა" მენიუდან "ინსტრუმენტები". ფანჯარაში, რომელიც იხსნება, ზედა ველში შეიყვანეთ საძიებო მოთხოვნა "Marlboro" და დააჭირეთ ღილაკს "ძებნა": 
მაგალითი 2ჩვენი ორგანიზაცია ქირავდება ოფისს რუმიანცევის ბიზნეს ცენტრთან ახლოს. აუცილებელია მონაცემთა ბაზაში სწრაფად მოიძებნოს 2010 წლის მარტის ქირავნობის აქტი. ჩვენ ვაკეთებთ შემდეგ საძიებო შეკითხვას: 
ვარიანტი 3.დავუშვათ, საქონლის გადაზიდვისას ჩვენ დავტოვეთ შემდეგი კომენტარი ზოგიერთ დოკუმენტში "საქონლისა და მომსახურების გაყიდვა" - "გადადებული გადახდა". და გვჭირდებოდა დაგვიანებით გაგზავნილი ყველა დოკუმენტის პოვნა. ჩვენ ვაკეთებთ შემდეგ საძიებო შეკითხვას: 
თქვენ ასევე შეგიძლიათ შეასრულოთ უფრო რთული ძებნა საძიებო ოპერატორების გამოყენებით (AND, OR, NOT, NEAR).
საძიებო ზონა შეიძლება შემოიფარგლოს კონკრეტული კონფიგურაციის ობიექტებით (მაგალითად, საქონლისა და სერვისების ქვითრის დოკუმენტი). ამისათვის დააჭირეთ ღილაკს "პარამეტრები": 
გამოჩნდება ველი კონფიგურაციის ობიექტის ასარჩევად. მონიშნეთ ველი „ძიების ფარგლების შეზღუდვა“ და დააწკაპუნეთ ღილაკზე „საძიებლად მეტამონაცემების ობიექტების არჩევა“: 
მაგალითად, აირჩიეთ დოკუმენტი "საქონლისა და მომსახურების მიღება". 
რჩება საძიებო მოთხოვნის შეყვანა და ძიება.
"მონაცემთა ძიების" დამუშავების ბოლოში აისახება ინდექსის შესაბამისობა. თუ ხედავთ - "ინდექსი არ არის განახლებული", თქვენ უნდა დააჭიროთ ღილაკს "განახლება ინდექსი".
სრული ტექსტის ძიება- საშუალებას გაძლევთ იპოვოთ ტექსტური ინფორმაცია გამოყენებული კონფიგურაციის თითქმის ნებისმიერ ადგილას. ამავდროულად, თქვენ შეგიძლიათ მოძებნოთ საჭირო მონაცემები ან მთლიანი კონფიგურაციის მასშტაბით, ან ძიების არეალის შევიწროებით რამდენიმე ობიექტზე (მაგალითად, გარკვეული ტიპის დოკუმენტები ან დირექტორიები). თავად ძიების კრიტერიუმები შეიძლება განსხვავდებოდეს საკმაოდ ფართო დიაპაზონში. ანუ, თქვენ შეგიძლიათ იპოვოთ საჭირო მონაცემები ისე, რომ არ დაიმახსოვროთ ზუსტად სად ინახება ისინი კონფიგურაციაში და ზუსტად როგორ არის ჩაწერილი.
სრული ტექსტის ძიება უზრუნველყოფს შემდეგ ფუნქციებს:
- არსებობს ტრანსლიტერაციის მხარდაჭერა (რუსული სიტყვების ლათინური ასოებით წერა GOST 7.79-2000 შესაბამისად). მაგალითი: "რუსული ფრაზა" = "რუსული ფრაზა".
- არსებობს ჩანაცვლების მხარდაჭერა (სიმბოლოების ნაწილის რუსული სიტყვებით დაწერა ერთი გასაღები ლათინური სიმბოლოებით). მაგალითი: "russrfz frapf" (თითოეული სიტყვის დაბოლოებები იბეჭდება ლათინურად, მაგალითად, ოპერატორის შეცდომის შედეგად).
- არსებობს ბუნდოვანი ძიების შესაძლებლობა (ნაპოვნი სიტყვების ასოები შეიძლება განსხვავდებოდეს) ბუნდოვანობის ზღურბლის მითითებით. მაგალითი: საძიებო სტრიქონში სიტყვის "გამარჯობა" და 17%-იანი ბუნდოვანის მითითებით ჩვენ ვიპოვით ყველა მსგავს სიტყვას შეცდომით და გარეშე: "გამარჯობა", "გამარჯობა", "მოიტანე".
- შესაძლებელია შერჩეული მეტამონაცემების ობიექტების ძიების ფარგლების დაზუსტება.
- სტანდარტული ველების სახელების სრული ტექსტური ინდექსირება ("კოდი", "აღწერა" და ა.შ.) შესრულებულია ყველა კონფიგურაციის ენაზე.
- ძიება ხორციელდება რუსული, ინგლისური და უკრაინული ენების სინონიმების გათვალისწინებით.
- რუსული ენის მორფოლოგიური ლექსიკონი შეიცავს უამრავ კონკრეტულ სიტყვას, რომლებიც დაკავშირებულია საქმიანობის სფეროებთან, რომლებიც ავტომატიზირებულია 1C: Enterprise პროგრამის სისტემის გამოყენებით.
- როგორც სტანდარტი, მოწოდებულ ლექსიკონებში შედის ლექსიკის მონაცემთა ბაზები და რუსული, უკრაინული და ინგლისური ენების თეზაურუსისა და სინონიმების ლექსიკონები, რომლებიც მოწოდებულია Informatik-ის მიერ.
- შეგიძლიათ მოძებნოთ ველური სიმბოლოების ("*"), ასევე საძიებო ოპერატორების ("AND", "OR", "NOT", "NEAR") და სპეციალური სიმბოლოების მითითებით.
სრული ტექსტის ძებნა შეიძლება შესრულდეს ნებისმიერი კონფიგურაციით 1C:Enterprise 8 პლატფორმაზე
სრული ტექსტის ძიების კონტროლის ფანჯრის გასახსნელად, გააკეთეთ შემდეგი:
ზოგადი განაცხადი- მენიუს ელემენტი ოპერაციები - სრული ტექსტის ძიების მართვა.
მართული აპლიკაცია- მენიუს ელემენტი მთავარი მენიუ - ყველა ფუნქცია - სტანდარტული -სრული ტექსტის ძიების მართვა.
- ინდექსის განახლება– ინდექსის შექმნა/ინდექსის განახლება;
- ინდექსის გასუფთავება– ინდექსის ნულიზაცია (რეკომენდებულია ყველა მონაცემის განახლების შემდეგ);
- პუნქტი ინდექსის შერწყმის დაშვება- პასუხისმგებელია ძირითადი და დამატებითი ინდექსის შერწყმაზე.
სრული ტექსტის ძიება ხორციელდება სრული ტექსტის ინდექსის გამოყენებით. ინდექსის არარსებობის შემთხვევაში, სრული ტექსტის ძებნა, როგორც ასეთი, შეუძლებელია. იმისათვის, რომ ძიება წარმატებული იყოს, ყველა საჭირო მონაცემი უნდა იყოს შეტანილი სრული ტექსტის ინდექსში. მომხმარებლის მიერ მონაცემთა ბაზაში ახალი მონაცემების შეტანის შემთხვევაში, ის უნდა იყოს შეტანილი მოცემულ ინდექსში, წინააღმდეგ შემთხვევაში ის არ მიიღებს მონაწილეობას ძიებაში. ამის თავიდან ასაცილებლად, თქვენ უნდა განაახლოთ სრული ტექსტის ინდექსი. განახლებისას სისტემა აანალიზებს მხოლოდ გარკვეული ტიპის მონაცემებს: სტრიქონი, საცნობარო ტიპის მონაცემები (დოკუმენტების ბმულები, დირექტორიები), ნომერი, თარიღი, ღირებულების შენახვა. თუ მომხმარებელს არ აქვს წვდომის უფლება გარკვეულ ინფორმაციაზე, მაშინ ის ვერ ნახავს მას ძიების შედეგებში. ასევე უნდა გვახსოვდეს, რომ ობიექტების თვისებები, რომლებითაც შესრულდება ძიება, უნდა იყოს მითითებული სრული ტექსტის ძიება - გამოყენება, რომელიც დაყენებულია ნაგულისხმევად.
როგორც ხედავთ ქონებას გამოყენებამითითებული მთელი დირექტორია კონტრაგენტები, მაგრამ ეს ასევე შეიძლება გაკეთდეს შესაბამისი ტიპის მისი თითოეული ატრიბუტისთვის.
მოდით უფრო დეტალურად განვიხილოთ სრული ტექსტის ინდექსი, რომელიც შედგება ორი ნაწილისაგან (ინდექსი): მთავარი და დამატებითი. Მაღალი სიჩქარემონაცემთა მოძიება უზრუნველყოფილია ძირითადი ინდექსის ხარჯზე, მაგრამ მისი განახლება შედარებით ნელა მიმდინარეობს, რაც დამოკიდებულია მონაცემთა რაოდენობაზე. დამატებითი ინდექსი მისი საპირისპიროა. მასში მონაცემები ემატება ბევრად უფრო სწრაფად, მაგრამ ძებნა უფრო ნელია. სისტემა ეძებს ორივე ინდექსს ერთდროულად. მონაცემების უმეტესობა მდებარეობს მთავარ ინდექსში, ხოლო სისტემაში დამატებული მონაცემები მთავრდება მეორად ინდექსში. რამდენადაც მეორად ინდექსში მონაცემების რაოდენობა მცირეა, მასში ძიება შედარებით სწრაფია. იმ დროს, როდესაც სისტემაზე დატვირთვა დაბალია, ხდება ინდექსის შერწყმის ოპერაცია, რის შედეგადაც ხდება დამატებითი ინდექსის გასუფთავება და ყველა მონაცემი მოთავსებულია მთავარ ინდექსში. სასურველია ინდექსების შერწყმა იმ დროს, როდესაც სისტემაზე დატვირთვა მინიმალურია. ამ მიზნით, თქვენ შეგიძლიათ შექმნათ რეგულირებული ამოცანები და დაგეგმილი ამოცანები.
სპეციალური ოპერატორები დაშვებულია საძიებო გამოხატვის მითითებისას
სრული ტექსტის ძიების მექანიზმი საშუალებას გაძლევთ დაწეროთ რუსული სიტყვის სიმბოლოების ნაწილი ერთი გასაღების ლათინური სიმბოლოებით. ძიების შედეგი არ შეიცვლება.
ორი ოპერატორი გვერდიგვერდ
- გამარტივებული. 8 სიტყვის დაშორებით
- NEAR/[+/-]n – მოძებნეთ მონაცემები ერთ ატრიბუტში მათ შორის n-1 სიტყვის მანძილზე.
ნიშანი მიუთითებს, თუ რომელი მიმართულებით მოიძებნება პირველი სიტყვიდან მეორე სიტყვა. (+ - შემდეგ, - ადრე)
სიმბოლო "*" შეიძლება გამოყენებულ იქნას მხოლოდ სიტყვის ბოლოს შემცვლელად
ბუნდოვანი ოპერატორი "#". თუ სახელის ზუსტი მართლწერა არ არის ცნობილი.
პროგრამული ინსტრუმენტები და ხელსაწყოები 1s: პროგრამირება.
სინონიმი ოპერატორი "!". საშუალებას გაძლევთ იპოვოთ სიტყვა და მისი სინონიმები
როგორ განვაახლოთ პროგრამულად სრული ტექსტის საძიებო ინდექსი?
კოდი 1C v 8.x პროცედურა UpdateIndexes() ექსპორტიFulltextSearch.UpdateIndex();
დასრულების პროცედურა
სრული ტექსტის მონაცემთა ძიების მაგალითი
ცვლადის განმარტება SearchList
კოდი 1C v 8.x ცვლადი SearchList;
გარდა ამისა, მოვლენის დამუშავების პროცედურაში, როდესაც ფორმა გაიხსნება, განვსაზღვრავთ, რომ ეს ცვლადი შეიცავს სრული ტექსტის საძიებო სიას, რომლის დახმარებითაც მოვიძიებთ მონაცემებში.
კოდი 1C v 8.x პროცედურა OnOpen()
SearchList = FullTextSearch.CreateList();
დასრულების პროცედურა
ახლა, Find ღილაკზე დაწკაპუნების შემთხვევაში, დავწეროთ კოდი, რომელიც მოგვცემს საშუალებას მოძებნოთ SearchExpression ველში მითითებული გამოთქმის შესაბამისად.
კოდი 1C v 8.x პროცედურა FindClick(Element)
SearchList.SearchString = SearchExpression;
მცდელობა
SearchList.FirstPart();
გამონაკლისი
გაფრთხილება(ErrorDescription());
მცდელობის დასასრული;
თუ SearchList.TotalCount() = 0 მაშინ
FormElements.MessageOResult.Value = "არ მოიძებნა";
FormElements.SearchResult.SetText("");
წინააღმდეგ შემთხვევაში
PrintSearchResult();
Დაასრულე თუ;
დასრულების პროცედურა
პირველ რიგში, ამ პროცედურაში, ჩვენ დავაყენეთ მომხმარებლის მიერ შეყვანილი საძიებო გამონათქვამი, როგორც სრული ტექსტის ძიების საძიებო სტრიქონი. შემდეგ ჩვენ ვასრულებთ FirstPart() მეთოდს, რომელიც რეალურად იწყებს სრული ტექსტის ძიებას და აბრუნებს შედეგების პირველ პარტიას. ნაგულისხმევად, ნაწილი შეიცავს 20 ელემენტს. ამის შემდეგ, ჩვენ ვაანალიზებთ ელემენტების რაოდენობას საძიებო სიაში. თუ ის არ შეიცავს რაიმე ელემენტს, მაშინ ჩვენ ვაჩვენებთ შესაბამის შეტყობინებას ფორმაში. წინააღმდეგ შემთხვევაში, გამოიძახება OutputSearchResult() პროცედურა, რომელიც უჩვენებს შედეგებს მომხმარებელს.
მოდით შევქმნათ იგივე სახელწოდების პროცედურა ფორმის მოდულში და ჩავწეროთ მასში კოდი,
კოდი 1C v 8.x პროცედურა DisplaySearchResult()
FormElements.MessageOResult.Value = "აჩვენა" + String(SearchList.StartingPosition() + 1) + " - " + String(SearchList.StartingPosition() +SearchList.Count()) + "from" + SearchList.FullCount();
შედეგი = SearchList.GetDisplay(FullTextSearchDisplayType.HTMLText);
FormElements.SearchResult.SetText(Result);
AccessibilityButtons();
დასრულების პროცედურა
ამ პროცედურის ნაბიჯები მარტივია. პირველ რიგში, ჩვენ ვქმნით შეტყობინებას იმის შესახებ, თუ რა ელემენტებია ნაჩვენები და რამდენი ელემენტი იქნა ნაპოვნი ჯამში. შემდეგ ვიღებთ სრული ტექსტის ძიების შედეგს HTML ტექსტის სახით და ვაჩვენებთ ამ ტექსტს ფორმაში მდებარე HTML დოკუმენტის ველში.
დაბოლოს, ჩვენ გადავიტანთ კონტროლს ButtonsAccess() პროცედურაზე, რათა ხელმისაწვდომი გავხადოთ ან, პირიქით, ავკრძალოთ წვდომა ღილაკებზე Previous ნაწილი და Next ნაწილი (დამოკიდებულია შედეგების რომელი ნაწილი იქნება ნაჩვენები). ამ პროცედურის ტექსტი წარმოდგენილია კოდექსში
კოდი 1C v 8.x ღილაკის ხელმისაწვდომობის პროცედურა()
FormElements.NextPortion.Availability = (SearchList.FullCount() - SearchList.StartPosition()) > SearchList.Quantity();
FormElements.PreviousPortion.Availability = (SearchList.StartPosition() > 0);
დასრულების პროცედურა
ახლა თქვენ უნდა შექმნათ მოვლენის დამმუშავებლები PreviousPortion() და NextPortion() ღილაკების დასაჭერად.
კოდი 1C v 8.x პროცედურა PrevPartPress(Element)
SearchList.PreviousPart();
PrintSearchResult();
დასრულების პროცედურა
პროცედურა NextBatchClick(პუნქტი)
SearchList.NextPart();
PrintSearchResult();
დასრულების პროცედურა
საბოლოო „შეხება“ იქნება ფორმაში მდებარე HTML დოკუმენტის ველის onclick მოვლენის ღონისძიების დამმუშავებლის შექმნა. ფაქტია, რომ სრული ტექსტის ძიების შედეგი, წარმოდგენილი როგორც HTML ტექსტი, შეიცავს ჰიპერბმულებს საძიებო სიის ელემენტების რაოდენობაზე. ჩვენ გვსურს, რომ სისტემამ გახსნას ამ სიის ელემენტში შემავალი ობიექტის ფორმა, როდესაც მომხმარებელი დააჭერს ამ ბმულს. ამისათვის ჩვენ ჩავჭრით HTML დოკუმენტის HTML დოკუმენტის ველში შემავალი onclick მოვლენას, ჰიპერბმულიდან მივიღებთ სიის ელემენტის ნომერს და გავხსნით შესაბამისი ობიექტის ფორმას. HTML დოკუმენტის ველის onclick მოვლენის დამმუშავებლის ტექსტი წარმოდგენილია კოდში
კოდი 1C v 8.x ProcedureSearchResultonclick(Element, pEvtObj)
htmlElement = pEvtObj.srcElement;
// შეამოწმეთ ელემენტის id
If (htmlElement.id = "FullTextSearchListItem") მაშინ
// მიიღეთ ფაილის სახელი (საძიებო სიის ხაზის ნომერი),
// შეიცავს ჰიპერბმულს
NumberInList = Number(htmlElement.nameProp);
// მიიღეთ საძიებო სიის სტრიქონი ნომრის მიხედვით
SelectedRow = SearchList[ListNumber];
// გახსენით ნაპოვნი ობიექტის ფორმა
OpenValue(SelectedRow.Value);
pEvtObj.returnValue = False;
Დაასრულე თუ;
დასრულების პროცედურა
