قرار گرفتن در یک گروه طبق سلسله مراتب 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" است، زیرا نمی تواند توافقی وجود داشته باشد که متعلق به هیچ طرف مقابل نباشد.

فیلد "List of Directory Owners" فهرست دایرکتوری هایی را که دارای عناصر این فهرست هستند مشخص می کند.

در زیر در قسمت "استفاده از تابع" نشان داده شده است که عناصر این دایرکتوری به چه مواردی وابسته خواهند بود.

چگونه می توان به صورت برنامه نویسی متوجه شد که آیا یک دایرکتوری سلسله مراتبی است یا خیر

برای این کار باید به ابرداده مراجعه کنید

این HierarchicalDirectory = Metadata.Directories.Counterparties.Hierarchical است.

ادامه دارد...

دایرکتوری های 1C یک شی درخت فوق داده تخصصی هستند که برای ذخیره اطلاعات مرجع استاتیک عمل می کنند. به عنوان مثال، در پیکربندی‌های معمولی می‌توانید نماهای زیر را مشاهده کنید: , نام‌گذاری, کارمندان, دارایی‌های ثابت و غیره. اطلاعات موجود در دایرکتوری ها معمولاً تغییر نمی کند. دایرکتوری ها متعاقباً تقریباً در تمام اشیاء حسابداری به عنوان بخش حسابداری یا اطلاعات مرجع استفاده می شوند.

در زیر به راه اندازی و طراحی دایرکتوری از پیکربندی کننده با استفاده از دایرکتوری "Nomenclature" به عنوان مثال نگاه خواهیم کرد.

برگه پایه

برگه "Basic" نام، مترادف، نمایش شی و شرح هدف را مشخص می کند.

برگه "دایرکتوری سلسله مراتب".

در اینجا سلسله مراتب دایرکتوری ایجاد می شود.

سلسله مراتب در 1C 8.3 دو نوع است - " گروه ها و عناصر"و" عناصر". تفاوت آن این است که در حالت اول فقط یک پوشه (گروه) می تواند والد (پوشه) باشد و در حالت دوم یک عنصر نیز می تواند والد باشد.

"قرار دادن گروه ها در بالا" - پرچم مسئول نمایش گروه ها در فرم لیست است.

همچنین در تنظیمات می توانید تعداد گروه ها را در سلسله مراتب دایرکتوری با استفاده از تنظیمات مناسب محدود کنید.

برگه مالکان

یک دایرکتوری را می توان به دایرکتوری دیگری وابسته کرد. از نقطه نظر پیکربندی 1C 8.3، این بدان معنی است که ویژگی "مالک" برای عنصر فرعی اجباری می شود. نمونه ای از چنین ارتباطی بین دایرکتوری ها در تنظیمات استاندارد "نامگذاری - واحدهای اندازه گیری"، "طرفداران - قراردادهای پیمانکاران".

مالک دایرکتوری همچنین می تواند اشیاء فوق داده زیر باشد: , .

برگه داده

267 درس ویدیویی را در 1C به صورت رایگان دریافت کنید:

مهمترین برگه از دیدگاه یک برنامه نویس. این شامل جزئیات دایرکتوری است.

فهرست دارای مجموعه‌ای از جزئیات استاندارد است که توسط برنامه‌نویس 1C 8.2 ویرایش نشده‌اند؛ فهرستی از آنها را می‌توان با کلیک کردن روی دکمه «جزئیات استاندارد» مشاهده کرد:

من در مورد هر یک با جزئیات بیشتر صحبت خواهم کرد:

این گروه- یک ویژگی با نوع بولی که نشان می دهد یک گروه یا یک عنصر است. فقط در فهرست سلسله مراتبی موجود است. توجه داشته باشید، مقدار این ویژگی را نمی توان در حالت 1C: Enterprise تغییر داد.
کد- props، عدد یا رشته را تایپ کنید (معمولاً یک رشته). شماره ای که به طور خودکار توسط سیستم اختصاص داده می شود. به طور معمول به عنوان (کد قبلی + 1) محاسبه می شود. توصیه می کنم از نوع رشته استفاده کنید، زیرا مرتب سازی مقادیر عددی آنطور که انتظار می رود کار نمی کند. می تواند به عنوان ارائه دایرکتوری در یک لیست و در فیلدهای ورودی استفاده شود. معمولاً برای جستجوی یک عنصر هنگام وارد کردن یک رشته استفاده می شود. اگر باید فیلد Code را حذف کنید، صفر را در طول خط وارد کنید.
نام- جزئیات اجباری، نوع رشته. حداکثر طول خط 150 کاراکتر است. می تواند به عنوان ارائه دایرکتوری در یک لیست و در فیلدهای ورودی استفاده شود. معمولاً برای جستجوی یک عنصر هنگام وارد کردن یک رشته استفاده می شود. اگر باید فیلد Name را حذف کنید، صفر را در طول خط وارد کنید.
والدین- یک ویژگی از نوع DirectoryLink.<ИмяТекущегоСправочника>. فقط در فهرست سلسله مراتبی موجود است. به والد برتر در سلسله مراتب اشاره می کند. اگر عنصر یا گروه در ریشه دایرکتوری باشد، مقدار Directory مشخص می شود.<ИмяТекущегоСправочника>.EmptyLink.
مالک- پیوند به عنصر مالک عنصر دایرکتوری فعلی (گروه). در دسترس فقط در دایرکتوری 1C فرعی.
حذف پرچم- لوازم با نوع Boolean. مسئول نمایش "علامت حذف" در سیستم. عنصری که برای حذف علامت گذاری شده است غیرقابل استفاده در نظر گرفته می شود، اما ممکن است حرکات سند قدیمی روی آن باقی بماند.
ارتباط دادن- فیلد نوع رشته این ویژگی یک شناسه شی منحصر به فرد - GUID را ذخیره می کند. آنچه ما در سیستم در یک صفحه نمایش بصری به نام "پیوند" می بینیم فقط نمایش یک شی است. قابل تغییر نیست.
از پیش تعریف شده- نوع بولی، نشان می دهد که آیا عنصر از پیش تعریف شده است یا خیر، در ادامه بیشتر در مورد آن. قابل تغییر نیست.

برگه "داده" همچنین نشان دهنده نمایش دایرکتوری در سیستم است؛ قبل از نسخه 8.2.16، نمایش فقط می توانست کد یا نام باشد. در نسخه های اخیر پلتفرم (شروع از 8.3)، نمای را می توان به طور مستقل در ماژول مدیر با استفاده از کنترلر "ViewReceivingProcessing" توصیف کرد.

برگه شماره گذاری

در اینجا می توانید تنظیمات دایرکتوری را در مورد شماره گذاری مشخص کنید. توصیه می شود از شماره گذاری خودکار استفاده کنید. کنترل منحصر به فرد پرچمی است که در صورت لزوم به منحصر به فرد کردن کد کمک می کند. اگر با تنظیم پرچم، سعی کنید یک عنصر دایرکتوری با یک کد غیر منحصر به فرد بنویسید، در 1C پیام "کد دایرکتوری غیر منحصر به فرد شده است" را دریافت خواهید کرد.

سری کد - نحوه شماره گذاری دایرکتوری را تعیین می کند؛ می توانید شماره گذاری دایرکتوری را توسط مالک وارد کنید. به عنوان مثال، طرف مقابل "Horns and Hooves" شماره قراردادهای خاص خود را خواهد داشت - "1، 2، 3" و غیره.

برگه فرم ها

فرم های دایرکتوری در اینجا توضیح داده شده است. اگر پیکربندی در هر دو حالت عادی و مدیریت شده راه اندازی شود، به طور پیش فرض دو برگه با فرم وجود خواهد داشت: "اصلی" و "پیشرفته" - برای برنامه های عادی و مدیریت شده متفاوت است.

این صفحه دارای یک ویژگی مهم دایرکتوری است - "". این یک عملکرد بسیار راحت 1C 8 است که به شما امکان می دهد هنگام پر کردن داده ها در قسمت ورودی، به دایرکتوری نروید، بلکه نام، کد و غیره آن را تایپ کنید. و عنصر مورد نظر را از لیست کشویی انتخاب کنید. به نظر می رسد این است:

برگه دیگر

در برگه می توانید به ماژول های اصلی دایرکتوری - ماژول شی و ماژول مدیر دسترسی سریع داشته باشید.

همچنین می توانید لیستی از عناصر دایرکتوری از پیش تعریف شده را در صفحه تعریف کنید. اینها مواردی هستند که در حالت Enterprise قابل حذف نیستند. عناصر از پیش تعریف شده را می توان مستقیماً با نام در پیکربندی کننده مشاهده کرد، به عنوان مثال: Directories.Nomenclature.Service.

این تب همچنین حالت مسدود کردن - خودکار یا کنترل شده را تعیین می کند. استفاده از جستجوی متن کامل، و همچنین اطلاعات مرجع در مورد دایرکتوری، موجود در 1C: حالت Enterprise.

طراحی "IN HIERARCHY" در جستارهای 1C:Enterprise 8.x به شما امکان می دهد عناصر فرعی یک شی پیکربندی سلسله مراتبی را با توجه به یک انتخاب معین بدست آورید. امروز در مقاله به نمونه ای از استفاده از آن و همچنین اقدامات پلت فرم در سمت DBMS و تأثیر آن بر عملکرد نگاه خواهیم کرد.

استفاده

بیایید به یک مثال ساده از استفاده از ساختار "IN HIERARCHY" نگاه کنیم. هنگام اجرای درخواست زیر، عناصر زیرمجموعه دایرکتوری سلسله مراتبی "محصولات" برای مقدار پاس شده از متغیر "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" به درخواستی در سمت پلت فرم ارسال کردیم. اما اگر پیوندی را به گروه سطح دوم "گروه - 1 - 1" به عنوان پارامتر "&Link" ارسال کنیم، پلتفرم چگونه رفتار خواهد کرد؟ همه چیز به همین ترتیب اتفاق می افتد، به جز نکته زیر: در بالا، در مرحله دوم اجرای کوئری های SQL توسط پلتفرم، نوشته شده بود که پرس و جو برای به دست آوردن عناصر فرعی دو بار اجرا شده است - در مورد به دست آوردن عناصر فرعی برای گروه "گروه - 1 - 1" اینطور نیست. درخواست فقط یک بار اجرا می شود.

واقعیت این است که تعداد درخواست ها برای به دست آوردن عناصر فرعی به تعداد گروه های سلسله مراتب بستگی دارد. به عبارت دیگر، اگر سطح سلسله مراتب عنصر شامل حداقل یک گروه باشد، درخواست از نقطه 2.

تاثیر عملکرد

استفاده نادرست از هر اپراتور در یک پرس و جو ممکن است منجر به عملکرد ضعیف سیستم شود. اپراتور تحت بررسی "IN HEERARCHY" نیز از این قاعده مستثنی نیست. باید با احتیاط استفاده شود، زیرا الگوریتم اجرای پرس و جوهای SQL در پایگاه داده را بسیار پیچیده می کند و در نتیجه بار روی سرور DBMS را افزایش می دهد.

اجازه دهید مثالی از یک پرس و جوی غیربهینه برای شما ارائه کنم که می تواند منجر به عواقب غم انگیز ذکر شده در بالا شود:

محصولات را انتخاب کنید. پیوند از دایرکتوری. محصولات به عنوان محصولات WHERE (محصولات. پیوند در سلسله مراتب (& پیوند) یا محصولات. پیوند در سلسله مراتب (& Link1) یا محصولات. پیوند در سلسله مراتب (& Link2) )

همانطور که ممکن است حدس بزنید، درخواست منجر به تولید پرس و جوهای SQL زیادی می شود که منجر به کاهش عملکرد سیستم اطلاعاتی می شود.

نتیجه گیری خود را انجام دهید!

نتیجه گیری به عهده شماست. اجازه دهید فقط بگویم که عملگر "IN HIERARCHY" توسط پلت فرم برای سیستم ترکیب داده ها استفاده می شود که شرایط انتخاب شامل "IN GROUP"، "IN GROUP FROM THE LIST" و موارد دیگر باشد. من فکر می کنم نیازی به توضیح نیست که با دستکاری های نادرست، کاربران می توانند انتخاب های بسیار پیچیده را تنظیم کنند و بار روی سرور 1C و DBMS را چندین بار افزایش دهند. بیایید تنظیمات را فقط برای کاربران با تجربه تغییر دهیم.

و البته، هنگام نوشتن مکانیسم های خود، به عملگر "IN HIERARCHY" توجه کنید. از یک طرف بسیار راحت و از طرف دیگر خطرناک است.

این بخش نمونه هایی از حل مسائل معمولی را هنگام کار با دایرکتوری های سلسله مراتبی نشان می دهد.

به دست آوردن عناصر یک فهرست سلسله مراتبی که تابع یک گروه معین هستند

برای به دست آوردن عناصر فرعی یک فهرست سلسله مراتبی، زبان پرس و جو ساختار IN HIERARCHY را ارائه می دهد. مثال استفاده در سلسله مراتب:

انتخاب کنید
نامگذاری.کد،
نامگذاری.قیمت خرید
از جانب

در این مثال، تمام رکوردهای فهرست نامگذاری که در گروه &گروه قرار دارد، شامل خود، گروه های تابع و عناصر متعلق به گروه های فرعی به دست می آید.

اگر ما فقط به عناصر و گروه هایی که مستقیماً در یک گروه معین قرار دارند علاقه مند هستیم، می توانیم با تنظیم یک شرط در قسمت Parent چنین عناصری را بدست آوریم. مثال:

انتخاب کنید
نامگذاری.کد،
نامگذاری نام AS نام،
نامگذاری.قیمت خرید
از جانب
Directory.Nomenclature AS Nomenclature

جایی که
Nomenclature.Parent = &Group

این پرس و جو گروه ها و عناصر وابسته به گروه را با پیوند &گروه انتخاب می کند.

بررسی وجود عناصر فرعی یک عنصر دایرکتوری

برای بررسی وجود رکوردهای فرعی یک عنصر دایرکتوری، می توانید از یک پرس و جو مشابه آنچه ارائه شده است استفاده کنید:

در این مثال، ارجاع به عنصری که می‌خواهید فرزندان آن را بررسی کنید، در پارامتر Query Parent نوشته می‌شود. پس از اجرای چنین کوئری، باید نتیجه را از نظر خالی بودن بررسی کنید. اگر نتیجه خالی نباشد، رکوردهای فرعی وجود دارد. در غیر این صورت - نه. مثال:

اگر Request.Execute().Empty() سپس
گزارش ("بدون ورودی")؛
در غیر این صورت
گزارش ("سوابق موجود")؛
endIf;

گرفتن همه والدین یک عنصر

زبان پرس و جو هیچ وسیله خاصی برای بازیابی همه والدین یک عنصر ارائه نمی دهد. می توانید از مجموع سلسله مراتبی برای تکمیل کار استفاده کنید، اما به دست آوردن مجموع سلسله مراتبی برای ساخت مجموع برای تعداد زیادی رکورد بهینه شده است و برای به دست آوردن والدین یک عنصر به طور کامل مؤثر نیست. برای بازیابی کارآمدتر تمام رکوردهای والد یک عنصر، توصیه می‌شود در بخش‌های کوچکی از طریق والدین آن حلقه بزنید. مثال:

CurrentItemItem = ItemItem;

در حالی که چرخه حقیقت
Request.SetParameter("CurrentItemItem", CurrentItemItem);
نتیجه = Query.Run();
If Result.Empty() سپس
سقط
endIf;
Selection = Result.Select();
Selection.Next();
برای ColumnNumber = 0 توسط Result.Columns.Quantity() - 1 حلقه
CurrentItemItem = Selection[ColumnNumber];
سقط
در غیر این صورت
گزارش (CurrentItemItem)؛
endIf;
چرخه پایان

اگر CurrentItemItem = Directories.Nomenclature.EmptyLink() سپس
سقط
endIf;
چرخه پایان

در این مثال، تمام والدین برای پیوند ثبت شده در متغیر ElementNomenclature در پنجره پیام سرویس نمایش داده می شوند. در چرخه، 5 والدین پیوند انتخاب می شوند.

اگر تعداد سطوح در فهرست محدود و کم باشد، می توان با یک درخواست بدون حلقه، همه والدین را به دست آورد.

نمایش دایرکتوری سلسله مراتبی در گزارش

برای نمایش یک دایرکتوری سلسله مراتبی در گزارش با حفظ سلسله مراتب، باید از یک پرس و جو مشابه موارد زیر استفاده کنید:

انتخاب کنید
نامگذاری.کد،
نامگذاری نام AS نام،
نامگذاری.قیمت خرید
از جانب
Directory.Nomenclature AS Nomenclature
مرتب سازی بر اساس
نام سلسله مراتب

این کوئری تمام رکوردها را از دایرکتوری انتخاب می کند و آنها را بر اساس سلسله مراتب مرتب می کند. نتیجه بر اساس نام و با در نظر گرفتن سلسله مراتب مرتب می شود.

برای اینکه گروه های دایرکتوری در بالای عناصر قرار گیرند، لازم است که عبارت ORDER BY در این درخواست با عبارت زیر جایگزین شود:

مرتب سازی بر اساس
نامگذاری. این سلسله مراتب گروه است،
نام

نتیجه همچنان به صورت سلسله مراتبی مرتب می شود، اما گروه ها در بالای عناصر ظاهر می شوند.

همچنین امکان جایگزینی پیشنهاد ORDER BY با گزینه AUTO ORDER وجود دارد. در این صورت، نتیجه مطابق با تنظیمات دایرکتوری، یعنی. اگر دایرکتوری بیان می کند که گروه ها باید بالای عناصر قرار گیرند، آنگاه در بالا قرار خواهند گرفت.

همچنین می توان با استفاده از نتایج به ساختار سلسله مراتبی دایرکتوری دست یافت.

انتخاب کنید
نامگذاری.کد،
نامگذاری نام AS نام،
نامگذاری.قیمت خرید

FROM Directory.Nomenclature AS Nomenclature

جایی که
(Nomenclature.ThisGroup = FALSE)

سفارش بر اساس نام

گرفتن مجموع بر اساس سلسله مراتب

برای بدست آوردن مجموع بر اساس سلسله مراتب در یک پرس و جو، باید پس از تعیین فیلدی که مجموع ها توسط آن محاسبه می شود، کلمه کلیدی HIERARCHY را در عبارت SOFTWARE TOTAL مشخص کنید. نمونه‌ای از گزارش "گردش کالا" با به دست آوردن مجموع بر اساس سلسله مراتب:

انتخاب کنید

از جانب

سلسله مراتب نامگذاری

در نتیجه این درخواست، مجموع نه تنها برای هر مورد، بلکه برای گروه هایی که این یا آن مورد به آنها تعلق دارد نیز محاسبه می شود.

در مواردی که به مجموع عناصر نیاز نداریم، بلکه فقط برای گروه ها به مجموع نیاز داریم، باید از ساختار HIERARCHY ONLY در مجموع استفاده کنیم. مثال:

انتخاب کنید
حسابداری برای NomenclatureTurnover.Nomenclature AS Nomenclature,
حسابداری برای نامگذاری گردش مالی. نامگذاری. ارائه،
حسابداری برای NomenclatureTurnover.QuantityTurnover AS QuantityTurnover
از جانب
انباشت ثبت نام. نامگذاری حسابداری. گردش مالی چگونه نامگذاری حسابداری گردش مالی
مقدار نتایج (تعداد گردش مالی) PO
نامگذاری فقط سلسله مراتب

نتیجه این پرس و جو کل رکوردها فقط برای گروه های آیتم خواهد بود.