1c dizininin önceden tanımlanmış öğeleri 8.3. Önceden tanımlanmış öğeler. Tipik konfigürasyona ekleme. Önceden tanımlanmış öğenin geçersiz belirtimi
İyi günler.
Bugün 8.3 platformunda önceden tanımlanmış öğelerle ilgili bir yenilikten bahsedeceğiz.
Tanıtım
Size hatırlatmama izin verin, daha önce, pratikte, önceden tanımlanmış adını bulmak için çok sık bir referans kitap öğesine bakmak istedim. Örneğin, önceden tanımlanmış iki yüklenici oluşturdunuz ve bunlara IPSidorov ve OOOMeteor adını verdiniz. Ve onlara bir çeşit mantık diktiler.
Her şey hata ayıklandığında ve çalıştığında, görevin tersine ayarlandığı ve LLC için tek mal sahibinin mantığına ihtiyaç duyulduğu ve LLC'nin mantığının tek mal sahibi için olduğu ortaya çıktı. “Sorun değil” diyoruz ve kurumsal modda öğeleri yeniden adlandırıyoruz. Kodun içine girmek çok daha zor. Bir yıl geçer ve size yeni bir görev verilir: IP Sidorov için biraz daha mantık kurmak. Konfigüratöre girersiniz, mantığı yazarsınız, kontrol etmeye başlarsınız ve hiçbir şey işe yaramaz, çünkü IPSidorov yapılandırıcısında ve işletmede - Meteor LLC. Beyin bozuldu ve ben bu tırmığı yok etmek istiyorum. En basit ve en sezgisel olanı, önceden tanımlanmış bir öğenin adını bir liste biçiminde çıktılamaktır. İşte bir pusu, 8.2'de önceden tanımlanmış olanın adını sadece yöntemle alabilirsiniz. Ve yöntemin kendi rahatsızlığı vardır, istekte elde edilemez. Onlar. ilk rahatsızlık, önceden tanımlanmış olanın adını dizine atıfta bulunarak almaktır.
İkinci rahatsızlık, zaten bir dizin elemanımız olduğunda ve onu önceden tanımlamamız gerektiğinde ortaya çıkar. Önceden tanımlanmış bir öğe oluşturuyoruz ve dizinde iki öğe alıyoruz. Biri önceden tanımlanmış, diğeri tüm belgelerimizin referans aldığı bir çalışma. Bağlantıları değiştirmek kesinlikle yardımcı olur, ancak veritabanı büyükse, o zaman zordur.
şimdi iş başında
Birincisi, referans kitabının artık "Ön tanımlı verileri güncelle" özelliğine sahip olmasıdır.
Bu alan bize ne veriyor? "Otomatik olarak güncelleme" olarak ayarlanmışsa, önceden tanımlanmış bir öğe ekleyerek onu hemen referansta göremeyiz. Onlar. meta verilerin verilerle hiçbir ilgisi yoktur. Ve dizinde oluşturulmamışsa, dizin yöneticisi aracılığıyla ona adıyla atıfta bulunulması sözdizimi hatasına neden olur.
Çok ilginç ama neden? Referansta bir öğeyi nasıl oluştururuz? Dilediğiniz gibi oluşturabilir veya mevcut bir tanesine bağlayabilirsiniz. Artık arama, "PredefinedDataName" özniteliğine sahiptir. "References.Contractors.CreateElement ()" aracılığıyla her zamanki gibi programlı bir şekilde bir katalog öğesi oluşturuyoruz ve "PredefinedDataName" özniteliğini önceden tanımlanmış öğenin adına eşit olarak dolduruyoruz. Veya eleman zaten mevcutsa, nesnesini alırız ve içindeki "ÖntanımlıVeriAdı"nı tekrar doldururuz. Her şey.
Ve son olarak, biraz şurup
Bu yeni aksesuarlar sadece okuma/yazma değil, aynı zamanda isteklerde de mevcuttur. Böylece sorgularda ona şartlar koyabilir, ön tanımlı olup olmadığını belirleyebilirsiniz.
Dikkatiniz için teşekkürler.
Dördüncü dersimizde programı tanımaya devam edeceğiz. Bugün tanışacağız vehiyerarşik dizinlerin yanı sıra önceden tanımlanmış öğelerin nasıl oluşturulacağını öğrenin.
Kursun 4 dersinin zamanlaması:
00:19
Kursun 3. dersi için ödev tamamlandıktan sonra çalışan kılavuzundaki değişiklikler
00:35
Dizinlerdeki niteliklerin sırasını düzenleme
02:54
Nomenklatür referans kitabının oluşturulması
03:40
Hiyerarşik bir dizin oluşturma ve yapılandırma
05:10
İsimlendirme dizininde Hizmetler ve Ürünler grupları oluşturma
06:05
Nomenklatür referans kitabının doldurulması
07:14
Bir dizin öğesini başka bir gruba taşımanın 3 yolu
08:21
Depolar dizininin oluşturulması
09:19
Önceden tanımlanmış katalog öğeleri oluşturma
11:25
Depolar dizininin doldurulması
12:20
Malzeme Testi Dersi 4'ü Alın
Hiyerarşik Dizin- öğelerinin hiyerarşik olarak düzenlenmesi olasılığına sahip bir referans kitabı. Örneğin, Nomenclature dizininde gruplar oluşturulabilir: Bu gruplara ait öğelerin bulunduğu Mallar, Hizmetler vb. Ek olarak, dizin grupları diğer grupları içerebilir, böylece çok seviyeli bir hiyerarşik yapı oluşturur.
Ayrıca sözlükler, sözlüklerin öğelerinin gruplara değil, aynı sözlüklerin diğer öğelerine ait olacağı başka bir hiyerarşi türünü destekler. Bu tür bir hiyerarşi ( eleman hiyerarşisi) örneğin, bir alt bölümün (bu durumda bir alt bölüm, dizinin bir öğesi, bir grup değil) birkaç başka alt bölümü içerebileceği dizin Alt Bölümleri oluşturulurken kullanılabilir. Bu tür bir hiyerarşi nadiren kullanılır.
Dizin formları- referans kitabının görsel sunumu. Dizinimiz ile ne tür işlemler yapmak istediğimize bağlı olarak, dizini "farklı görünümlerde" görüntülememiz gerekiyor. Bu yüzden dersin 4. dersinde, gerekliliklerin sırasını bir liste şeklinde ve bir referans elemanı şeklinde düzenledik.
Sistem formları otomatik olarak oluşturur (oluşturur), ancak gerekirse geliştirici formları kendi başına "çizebilir".
Toplamda, referans kitaplar için 5 form (form türü) vardır:
- eleman şekli- bir dizin öğesi oluşturmak veya düzenlemek için;
- grup şekli- bir dizin grubu oluşturmak veya düzenlemek için;
- liste formu- dizin öğelerinin bir listesini görüntülemek için;
- seçim formu- belirli bir formun alanında bu dizinin öğelerinden birini seçmek için kullanılır. Örneğin depo alanında Mal girişi belgesinde Depolar dizininden belirli bir depo seçmek için;
- grup seçim formu- belirli bir formun bir alanında bu dizinin gruplarından birini seçmek için kullanılır.
Önceden Tanımlanmış Dizin Öğeleri- Yapılandırıcı modunda geliştirici tarafından oluşturulan ve yerleşik 1c dilinden Ad ile erişilebilen dizin öğeleri.
Normal ve önceden tanımlanmış dizin öğeleri arasında temel bir fark vardır. Normal öğeler yapılandırmada tutarsız. Kullanıcının çalışması sırasında bunlar oluşturulabilir, düzenlenebilir ve silinebilir ve bu nedenle herhangi bir algoritma yürütülürken bunlara güvenilmemelidir (elemanın kodu ve adı kullanıcı tarafından değiştirilebilir).Buna karşılık, önceden tanımlanmış öğeler kalıcıdır. Çalışma sürecinde, kullanıcı böyle bir öğeyi yeniden adlandırsa bile, yerleşik 1c dilinden ona erişmek mümkün olacaktır. Bu, önceden tanımlanmış öğenin bir props'a sahip olması nedeniyle elde edilir. İsim hangi kullanıcı için mevcut değildir. Dizinin sıradan öğelerinin böyle bir özelliği yoktur.
Önemli! Teknik olarak, kullanıcının önceden tanımlanmış bir katalog öğesini silme yeteneği vardır, ancak bir kural olarak, kullanıcıların önceden tanımlanmış katalog öğelerini silme hakları devre dışı bırakılır.
Dersin 4. dersi için ödev
Kursun dördüncü dersi için ödevler, teori testini başarıyla çözdükten hemen sonra size sunulacaktır.
Yazdır (Ctrl + P)
Nesne yöneticisini kullanarak önceden tanımlanmış değerlerle çalışma
İlgili nesnenin yöneticisini kullanarak 1C: Enterprise sunucu tarafında önceden tanımlanmış bir değer elde edebilirsiniz. Alınan sahne öğelerini tanımlayan dize şöyle görünür:
ÖntanımlıDeğerTürüMeta veriNesneAdıDeğer
● Öntanımlı Değer Türü- önceden tanımlanmış değerleri elde etmek için aşağıdaki veri türleri belirtilebilir (yazarak
çoğul):
● Dizinler,
● Tip ve Nitelik Planları,
● Hesap Planları,
● Hesaplama Türlerinin Planları,
● Listeler.
● NesneAdıMeta Veri
● Değer - aşağıdakilerden biri olabilir:
● numaralandırmalar için numaralandırma değerinin adı belirtilir;
● Rota Noktaları Nokta Adı, iş sürecinin bir rota noktasıdır.
Bir iş sürecinin rota noktasını almanız gerekirse, alınan değeri açıklayan satır şöyle görünecektir:
BusinessProcesses.ObjectNameMetadata.RoutePoints.RoutePointName
Örnek:
Görünüm = Numaralandırmalar.Mal Türleri.Ürünler;
// Ön tanımlı arama verileri alınıyor.
Öğe = Dizinler.Currency.RUB;
// İş sürecinin rota noktası
Nokta = İş Süreci Onaylama Rota Noktaları Onay;
Önceden tanımlanmış değerlerle çalışma Bir fonksiyon kullanma Öntanımlı Değer ()
İstemci tarafında uygulama nesnelerinin bulunmaması nedeniyle, nesne yöneticilerini kullanarak önceden tanımlanmış öznitelikleri elde etmek imkansız hale gelir. Bu nedenle, onları elde etmek için PredefinedValue () global bağlamının bir yöntemi vardır. Bu yöntemin parametresi, almak istediğiniz önceden tanımlanmış değeri tanımlayan bir dizedir. Önceden tanımlanmış bir değeri açıklamaya yönelik sözdizimi, sorgu dilindeki DEĞER operatörüyle aynıdır.
Alınan sahne öğelerini tanımlayan dize şöyle görünür:
Bu hattın bileşenlerini daha ayrıntılı olarak ele alalım:
● Öntanımlı Değer Türü- önceden tanımlanmış değerleri elde etmek için aşağıdaki veri türleri belirtilebilir (yazarak
tekil):
● Dizin,
● PlanTürlerÖzellikler,
● Hesap Planı,
● Planı Görüntüle,
● Numaralandırma,
● İş Süreci.
● ve NesneAdıMeta Veri- meta veri nesnesinin adı, yapılandırıcıda belirtildiği gibi belirtilir.
● Değer - aşağıdakilerden biri olabilir
● numaralandırmalar için numaralandırma değerinin adı belirtilir;
● önceden tanımlanmış bir değer elde etmek için, adı konfigüratörde belirtildiği gibi belirtilir;
● Rota Noktası Nokta Adı - iş sürecinin rotasının noktası;
● BlankLink - boş bir bağlantı almak için.
Sistem numaralandırmasının değerini almanız gerekiyorsa, yöntem parametresi şöyle görünecektir:
SystemEnumerationName.SystemEnum değeri.
Örneğin:
ChartType = PredefinedValue (“ChartType. ConcaveSurface“);
Bir iş sürecinin rota noktası almanız gerekiyorsa, alınan değeri açıklayan satır şöyle görünecektir:
Örnek:
// Numaralandırma değerini al.
Tür = Öntanımlı Değer("Sayılama. Mal Türleri. Mallar");
// Boş bir bağlantının değerini alın.
BoşRef =
Önceden Tanımlanmış Anlam(“Belge.Fatura.BoşBağlantı”);
// Ön tanımlı arama verileri alınıyor.
Öğe = Öntanımlı Değer("Dizin. Para Birimi. Rublesi");
// İş sürecinin rota noktası
Nokta = Önceden Tanımlanmış Değer(“İş Süreci. Onay. Rota Noktası. Onay”);
Bence önceden tanımlanmış öğelerle programlı olarak çalışma fikri çok doğru. Çalışırken dikkate alınması gereken bazı nüanslar var.
İlk olarak, konfigürasyonda önceden tanımlanmış öğeler olduğunu ve bilgi tabanında (IB) önceden tanımlanmış öğeler olduğunu kendiniz açıkça anlamalısınız. Teknik olarak önceden tanımlanmış bilgi güvenliği öğeleri, "PredefinedDataName" özniteliğinin hangi önceden tanımlanmış yapılandırma öğesine karşılık geldiğini belirttiği sözlüklerin en yaygın öğeleridir. Sıradan unsurlardan artık farklı değiller. Buna göre, herhangi bir sıradan IB elemanı önceden tanımlanmış, herhangi bir önceden tanımlanmış sıradan yapılabilir. Bunu yapmak için, aksesuarlara istediğiniz değeri girin. "Öntanımlı VeriAdı".
Periyodik olarak, bu özelliğin geliştiricinin sağladığı değer olmadığı ortaya çıkıyor. Sonuç olarak, 1C'nin çalışmasında hatalar meydana gelir. Prensipte işin imkansız olduğu kritikten, algoritmaların mantığının ihlal edildiği kritik olmayana.
Koşullu olarak ayırt edilebilir üç tür hata:
1. "Verilerde önceden tanımlanmış öğe eksik";
3. Önceden tanımlanmış bir öğenin geçersiz gösterimi;
1. "Verilerde önceden tanımlanmış bir öğe eksik" - o IB verilerindeki konfigürasyonda açıklanan önceden tanımlanmış bir öğenin olmaması.
Bu, hata ayıklaması ve düzeltmesi en kolay hata türüdür. Basitliği, platformun bu durum hakkında yeterince doğru bir şekilde "Verilerde önceden tanımlanmış bir öğe eksik" rapor etmesi ve bunun nasıl düzeltileceği oldukça açık.
"Directories.Types of ContactInformation.EmailContactPerson" kodundaki eksik öğeye erişirken mesaj görüntüleniyor
"DEĞER (Directory.Types of ContactInformation.EmailContactPerson)" isteğindeki bir öğeye atıfta bulunulduğunda aşağıdaki mesaj görüntülenir:
Bu hata, yapılandırmada bir öğe tanımlanmışsa, ancak öğe veritabanında onunla ilişkilendirilmemişse oluşur.
Öncelikle bu durumun her zaman yanlış olmadığını açıklığa kavuşturalım. Çoğu kullanıcı için kullanılamayacak olan bir tür program mantığında önceden tanımlanmış verileri kullanmak oldukça mümkündür. Bu durumda, konfigürasyonun tüm kullanıcıları için referans kitabını karmaşıklaştırmamak için, konfigürasyonda önceden tanımlanmış öğeleri tanımlamak, ancak bunları tüm bilgi güvenliği sistemlerinde oluşturmak değil, yalnızca bu bilgi güvenliği sistemleri için oluşturmak mantıklıdır. gerekli yapılandırma mantığının kullanıldığı. Bu durumda, programcı referans kitabı için "Önceden tanımlanmış verileri güncelleme" özelliğini belirleyebilir ve modülün işlevselliğine erişirken programlı olarak öğeler oluşturabilir. Veya kullanıcının modülün önceden tanımlanmış öğelerini sahip olduğu olağan öğelere bağımsız olarak bağlamasını sağlamak.
Ayrıca, RIB modunda çalışırken önceden tanımlanmış öğelerin otomatik olarak oluşturulması kullanılmaz. Çünkü yeni elemanlar merkezi tabandan transfer edilmelidir ve farklı UID'lere sahip düğümlerde oluşturulmamalıdır.
Onlar. bazen böyle bir öğenin varlığından ziyade eşsiz bir öğeye atıfta bulunmak bir hatadır.
Öğenin neden oluşturulmadığını analiz etmeniz gerekir. Belki de programın bazı modları yürütüldüğünde oluşturulmalıdır. Örneğin, RIB'de bir değişim gerçekleştirdikten sonra. Ya da belki de yanlışlıkla silinmiştir.
Mantık, önceden tanımlanmış öğeleri otomatik olarak değil, ayrı bir modda doldurmayı sağlıyorsa, çağrıyı kullanmadan önce " Dizinler.İletişim TürleriBilgi.EmailİletişimKişi"Bir istisnayı önlemek için, öğenin veritabanında olup olmadığını kontrol etmeniz önerilir. Öğe yoksa, kullanıcıyı bu konuda bilgilendirin ve öğeyi doldurmak için hangi modu yürütmesi gerektiğini açıklayın. Böyle bir kontrol için, veriler üzerinde bir sorgu çalıştırabilirsiniz.
İstek = Yeni İstek; Request.Text = "SEÇ | İletişim Bilgisi Çeşitleri.Link | FROM | Rehber.İletişim Bilgisi Türleri AS İletişim Bilgisi Çeşitleri | NEREDE | İletişim Bilgisi Çeşitleri. Öntanımlı Veri Adı =" " E-postaİletişimKişi"" "; ElementNoNo.VD = Request.Run().Boş();
Bu hala veritabanı verilerinde bir hataysa, o zaman IB öğesinin önceden tanımlanmış bir öğesine bağlanmak gerekir. Onlar. program kodunun hangi IS öğesine bu adla atıfta bulunacağını sisteme açıklamak gerekir. Teknik olarak, bağlama sadece bir özellikte önceden tanımlanmış bir öğenin adını belirtmektir "ÖntanımlıVeriAdı"IB öğesi. Yüklemek için şu kodu çalıştırmanız yeterlidir:
2. "Önceden tanımlanmış öğe benzersiz değil" - h advoi önceden tanımlanmış öğeler:
Bu durum, birkaç IB öğesinin önceden tanımlanmış bir öğeye bağlı olması gerçeğinden oluşur. Bu durumda, önceden tanımlanmış bir isme atıfta bulunulurken, eleman rastgele seçilecektir. Bu durum her zaman yanlıştır. Zorluğu, platformun bu konuda hiçbir şekilde iletişim kurmaması gerçeğinde yatmaktadır. Sadece algoritmalar yanlış çalışmaya başlıyor.
Çerçeve, yinelenen bir öğeyi düzenlemeye çalışırken yalnızca "Önceden tanımlanmış öğe benzersiz değil" hatasını bildirir.
Hiç kimsenin öğeyi düzenlemesi gerekmeyene kadar, hiç kimse hatayı bilmeyecek.
Bu tür kopyalar, örneğin referans kitabı için RIB kullanılıyorsa ve önceden tanımlanmış veriler için özelliklerde "Otomatik olarak güncelle" modu belirtilmişse oluşturulabilir. Bu durumda, değişim gerçekleştirildiğinde, konfigürasyon güncellendiğinde önceden tanımlanmış verilerin bir örneği oluşturulacaktır. Aynı ada sahip önceden tanımlanmış öğelerin ikinci bir örneği, değişim sırasında merkezi veritabanından aktarılacaktır.
Ayrıca, farklı bilgi güvenliği öğelerinin farklı veritabanlarında önceden tanımlanmış öğelere karşılık gelmesi durumunda, yapılandırmalar arasında değiş tokuş işlemi kullanılırken bu kopyalar ortaya çıkacaktır. Bu durumda, önceden tanımlanmış verilerin bir kopyası veritabanında zaten var, ikincisi ise farklı bir UID ile veri yüklenirken gelecek. Veri aktarımı yapıyorsanız, hangi veritabanı öğelerinin birincil kabul edildiğine karar vermeniz ve bunları alt veritabanında kullanmanız gerekir. Alt tabanda, eski elemanların kullanımını ana tabanın elemanları ile değiştirmek gerekir.
Veritabanındaki bu tür hatalar, formun bir sorgusu ile tespit edilebilir:
İletişim Bilgileri Türlerini SEÇİN .Önceden TanımlıVeri Adı, MİKTAR (FARKLI İLETİŞİM BİLGİLERİ TÜRLERİ.Link) Rehberden Önceden Tanımlanmış Bir Numara OLARAK.İletişim Bilgisi Türleri OLARAK İletişim Bilgisi Türleri.
Bu sorgu, kendisiyle ilişkilendirilmiş birden fazla IB öğesiyle önceden tanımlanmış öğelerin bir listesini döndürür.
Bu tür öğeler varsa, bunlardan biri için önceden tanımlanmış olanla olan bağlantıyı kaldırmak gerekir. Onlar. Bu adı kullanırken program kodunun hangi IS öğesine atıfta bulunması gerektiğini sistem için açık bir şekilde belirlemek gerekir. Bunu yapmak için kodu çalıştırmanız yeterlidir.
3. Önceden tanımlanmış bir öğenin geçersiz gösterimi.
Hata, önceden tanımlanmış öğenin, program mantığı tarafından sağlanan yanlış öğeye karşılık gelmesi gerçeğinde yatmaktadır. Bu tür hatalar teşhis edilmesi en zor olanlardır. İlk iki türden farklı olarak, bu hatalar için yapılandırmayı otomatik olarak kontrol edemezsiniz. Sadece işin mantığı analiz edilerek tanımlanabilirler. Şüpheniz varsa, doğru öğenin kullanılıp kullanılmadığını kontrol edebilirsiniz.
Bunu yapmak için, komutlardan birini yürütmeniz yeterlidir.
// Gerekli önceden tanımlanmış Rapora bağlı bir IB öğesinin tanımı (Directories.Types of ContactInformation.EmailContactPerson) // Seçilen Raporun bağlı olduğu önceden tanımlanmış öğeyi belirleyin (ReferenceOnItem.Name of PredefinedData)
Bu tür hatalar bulunursa, eski eleman ile yanlış bağlantıyı kaldırmak ve yeni eleman ile bir bağlantı eklemek gerekir. İşlem kodu, ilk iki tür hata için düzeltme koduna benzer.
Peki, program çalışması sırasındaki veya yapılandırıcı modundaki hatalar hakkında kısaca:
"Önceden tanımlanmış öğe,<Имя справочника>" - ortak yapılandırıcıdaki adla eşleşmeyen bir adla önceden tanımlanmış bir öğe yazmaya çalışırken bir hata oluşur.
"Önceden tanımlanmamış nesneler, önceden tanımlanmış alt konto türü girişlerine sahip olamaz" - önceden tanımlanmış bir hesap planı öğesini tanımsız yapmaya çalıştığınızda bir hata oluşur. Hataları ortadan kaldırmak için, öğenin alt sözleşmesinin her satırı için "Önceden tanımlanmış" bayrağının işaretini kaldırmak gerekir.
"Önceden tanımlanmamış nesneler, önde gelen hesaplama türlerinin önceden tanımlanmış kayıtlarına sahip olamaz"- hesaplama türleri tablosunun önceden tanımlanmış bir öğesini tanımsız yapmaya çalıştığınızda bir hata oluşur. Hataları ortadan kaldırmak için, önde gelen eleman hesaplama türünün her satırı için "Ön tanımlı" bayrağını temizlemek gerekir.
"Önceden tanımlanmış öğeler benzersiz değil"- bilgi tabanını 8.3.4 uyumluluk modu olmadan bir yapılandırma sürümüne güncellerken yapılandırıcıda bir hata görüntüleniyor. Güncellemeden önce kopyaları kontrol etmek ve ortadan kaldırmak gerekir.
"Önceden tanımlanmış öğenin adı benzersiz değil" - platforma güncelleme yapılırken konfigürasyonda aynı ada sahip önceden tanımlanmış birkaç öğe varsa hata oluşur8.3.6.2332 ve sonrası. Konfigürasyondaki kopyaları ortadan kaldırmak gerekir.
Önceden tanımlanmış verilerle çalışmak için işlemeyi öneririm. Önceden tanımlanmış verilerle herhangi bir işlemin nasıl gerçekleştirileceğini bilir ve tüm bilgi güvenliği nesnelerinde (referans defterleri, hesap çizelgeleri, PVC) ilk iki türdeki (yinelenen ve eksik öğeler) hataların olup olmadığını bir bütün olarak yapılandırmayı kontrol edebilir. , PVR).
1C: Enterprise 8.x platformunda çalışırken, genellikle program kodunu normal (önceden tanımlanmamış) dizin öğelerine bağlamak gerekir. Örneğin, bir kuruluş, hemen hemen tüm mekanizmalarda kullanılan beş tür fiyata sahip olabilir. Aynı zamanda, belirli bir fiyata programlı erişim, en iyi ihtimalle ya referans kitabındaki bir kodla, en kötü ihtimalle öğenin adıyla gıcırdayarak gerçekleştirilir.
İstenen fiyatı elde etmek için raporlarda, fiyat türüne göre seçimin ismine göre bir talepte kullanıldığına tanık oldum (bir sonraki ekran görüntüsüne bakın).
Ek olarak, dizin öğelerinin adına veya koduna bağlanırsanız, öğeye bir bağlantı aldığınızda, her zaman dizin tablosunda bir arama yapılır. Standart sistem özniteliklerinin DBMS tarafından indekslenmesine rağmen, bazı durumlarda bunlar üzerinde yapılan arama önemli kaynakları kaplayabilir. Ek olarak, diyelim ki öğeye olan bağlantı zaten "önceden biliniyorsa", arama tablosunda bir arama sorgusu yapmamak daha mantıklı olacaktır.
Bir çıkış yolu olarak, "Ürün Fiyat Türleri" aramasında sık kullanılan her bir öğeye bir referansı ayrı sabitlerde saklayabilir ve sorguda bunlardan değerler alabilirsiniz. Ancak bu durumda geliştiricinin bu tür her bir öğe için ayrı bir sabit eklemesi gerekecektir. Bu tür öğeler yalnızca "Ürün Fiyat Türleri" dizininde değil, aynı zamanda diğer dizinlerde de ("Nesne Kategorileri", "Kalite", "Terminoloji" ve diğerleri) varsa, durum çok daha karmaşık hale gelecektir. Daha sonra sistemdeki sabitlerin sayısı birkaç kat artabilir!
Elbette, dizinlerin her birine önceden tanımlanmış öğeler eklenebilir ve bunlara erişmek çok daha kolay olurdu. Ancak, genel nesnelerin değiştirilmesi, satıcı paketlerinden yapılandırmanın güncellenmesi sürecini karmaşık hale getirecektir.
Hem konfigürasyon meta veri yapısını geliştirme açısından hem de sistem performansı açısından daha iyi bir yaklaşım var. Bugün onun hakkında konuşacağız.
Tek elden çözüm
Evrensel bir çözümün özü şu şekilde olacaktır: geliştiricinin önceden tanımlanmış öğeleri ekleyeceği bir referans oluşturulacaktır. Türü "Ön tanımlı sözlük öğesi -> İlişkili değer" yazışmasının oluşturulacağı değerlere bağlı olan sözlüğe "Değer" değişkeni eklendi. Dizin meta veri yapısı şöyle görünür (bir sonraki ekran görüntüsüne bakın).
Önceden tanımlanmış bir öğe elde etmek için en iyi seçenek global yöntemi kullanmaktır. "Öntanımlı Değer (<Имя>)" ... Önceden tanımlanmış öğenin tam yolu, yönteme parametre olarak iletilir. Sözdizimi, "DEĞER ()" sorgu dili işlevine benzer.
Geliştirme kolaylığı için, önceden tanımlanmış bir öğeyle ilişkili değeri ortak bir modüle almak için işlevi taşımanızı öneririm. Makalenin sonundaki bağlantıdan indirilebilen test yapılandırmasında, dışa aktarma işlevine sahip ortak bir "Önceden Tanımlı Öğe Değerleri" modülü oluşturulmuştur. "GetValuePredefinedElement (<ИмяПредопределенногоЭлемента>)" ... İşlevin program kodu, önceden tanımlanmış bir öğeye bir bağlantı alır, ardından istek üzerine "Değer" özniteliğinin değerlerini alır. Aşağıdaki ekran görüntüsü, işlevin tam listesini gösterir.
Gördüğümüz gibi işlev, parametre olarak iletilen önceden tanımlanmış öğenin "Değer" özniteliğine bir istek oluşturur. function parametresi, önceden tanımlanmış bir öğenin adına sahip bir dizedir.
Oluşturulan mekanizmanın düzgün çalışması için, kullanıcı modunda "Değer" özniteliğinde karşılık gelen öğeyi seçerek önceden tanımlanmış bir öğeyi normal bir katalog öğesiyle bağlamanız gerekir. Performans üzerindeki etki konusuna geçelim.
performans üzerindeki etkisi
Her iki arama seçeneği için bir hız testi gerçekleştirdi: ada göre ve önceden tanımlanmış bir öğeden referansa göre. Arama, 20.000 kayıt içeren "Ürünler" dizininde yapıldı. Bir dosya veritabanı üzerinde testler yapılırken aşağıdaki sonuçlar elde edildi:
Sonuçlar, çalışmanın dosya sürümü için, diğer dizinlerin sık kullanılan öğelerini almak için önceden tanımlanmış öğeleri kullanmanın neredeyse 4 kat daha yavaş çalıştığını gösterdi!
Çalışmanın istemci-sunucu versiyonunda ise test sonuçları tamamen farklı bir resim gösteriyor. İstenen öğeye bağlantı elde etme hızı önemli ölçüde azalmadı (testlerden biri 0,002 saniye gösterdi. Ada göre arama için ve 0,0008 saniye. Önceden tanımlanmış bir öğe üzerinde çalışırken), ancak programın güvenilirliği önemli ölçüde arttı!
sonuçlar
Sıradan dizin öğelerine genellikle bağlanmanın gerekli olduğu durumlarda, kod veya adla bağlama kullanmamanızı öneririm. Bu yaklaşım, sistemin güvenilirliğini ve performansını azaltır.
Platformla çalışma sırasında, örneğin "PriceNomenclature Types" referans kitabının öğesi için adı değiştirdikten sonra standart dışı raporların çoğunun düştüğü durumlarla defalarca karşılaştım.
Sıradan dizin öğeleriyle bir kod veya ad aracılığıyla ne kadar çok algoritma ilişkilendirilirse, sistem o kadar az kararlı olur.
Ayrıca, bu yaklaşım, onlara önceden tanımlanmış bir öğe eklemeniz gerekiyorsa, tipik yapılandırma nesnelerini değiştirmemenize izin verecektir. Gelecekte bu, yapılandırmayı güncelleme sürecini biraz daha kolaylaştıracaktır.
İndirilenler:
- Makaleden örneklerle test tabanını boşaltma.