Adresáre 1C sú špecializovaným objektom stromu metadát, ktorý sa používa na ukladanie statických informácií referenčného charakteru. Napríklad v typických konfiguráciách môžete vidieť nasledujúce zobrazenia: , Nomenklatúra, Zamestnanci, Dlhodobý majetok atď. Informácie v adresároch sa spravidla často nemenia. Referenčné knihy sa ďalej používajú takmer vo všetkých účtovných objektoch ako účtovná časť alebo referenčná informácia.
Nižšie zvážime nastavenie a navrhnutie referenčnej knihy z konfigurátora pomocou referenčnej knihy „Nomenklatúra“ ako príkladu.
Karta Všeobecné
Záložka „Základné“ označuje názov, synonymum, znázornenie objektov, popis účelu.
Záložka Hierarchia adresára
Tu sa nastavuje hierarchia adresárov.
Hierarchia v 1C 8.3 je dvoch typov - " skupiny a prvky"A" prvkov". Líši sa tým, že v prvom prípade môže byť rodičom (priečinkom) iba priečinok (skupina) a v druhom prípade môže byť rodičom aj prvok.
"Umiestniť skupiny navrch" - príznak je zodpovedný za zobrazenie skupín vo forme zoznamu.
Taktiež v nastaveniach môžete príslušným nastavením obmedziť počet skupín v hierarchii adresárov.
Karta Vlastníci
Adresár môže byť podriadený inému adresáru. Z hľadiska konfigurácie 1C 8.3 to znamená, že atribút „Vlastník“ sa stáva povinným pre podriadený prvok. Príklad takéhoto prepojenia adresárov v typických konfiguráciách „Nomenklatúra – merné jednotky“, „Dohody medzi zmluvnými stranami“.
Vlastníkom adresára môžu byť aj nasledujúce objekty metadát: , .
Karta Údaje
Získajte 267 1C video lekcií zadarmo:
Najdôležitejšia záložka z pohľadu programátora. Obsahuje podrobnosti o adresári.
Adresár má súbor štandardných podrobností, ktoré neupravuje programátor 1C 8.2, ich zoznam si môžete pozrieť kliknutím na tlačidlo „Štandardné podrobnosti“:
Budem sa venovať každému podrobnejšie:
- Táto skupina— atribút s booleovským typom označujúcim, či ide o skupinu alebo prvok. Dostupné iba v hierarchickom adresári. Poznámka, hodnotu tohto atribútu nie je možné zmeniť v režime 1C: Enterprise.
- kód- atribút, číslo typu alebo reťazec (zvyčajne reťazec). Číslo pridelené automaticky systémom. Zvyčajne sa vypočíta ako (predchádzajúci kód + 1). Odporúčam použiť typ reťazca, pretože triedenie číselných hodnôt nefunguje tak, ako by malo. Dá sa použiť ako pohľad na vyhľadávanie v zozname a vo vstupných poliach. Zvyčajne sa používa na vyhľadávanie prvku pri zadávaní reťazca. Ak potrebujete odstrániť pole Kód, zadajte do dĺžky reťazca nulu.
- názov— atribút, ktorý je potrebné vyplniť, typ reťazca. Maximálna dĺžka riadku je 150 znakov. Dá sa použiť ako pohľad na vyhľadávanie v zozname a vo vstupných poliach. Zvyčajne sa používa na vyhľadávanie prvku pri zadávaní reťazca. Ak potrebujete odstrániť pole Názov, zadajte do dĺžky reťazca nulu.
- Rodič— atribút typu ReferenceReference.<ИмяТекущегоСправочника>. Dostupné iba v hierarchickom adresári. Ukazuje na najvyššieho rodiča v hierarchii. Ak je prvok alebo skupina v koreňovom adresári, zadá sa hodnota Directory.<ИмяТекущегоСправочника>.EmptyReference.
- Vlastník— odkaz na vlastníka prvku aktuálneho prvku (skupiny) adresára. K dispozícii iba v podriadenom adresári 1C.
- FlagRemoval— rekvizity s booleovským typom. Zodpovedá za zobrazovanie „značky vymazania“ v systéme. Prvok označený na vymazanie sa považuje za nepoužiteľný, ale staré pohyby v dokumentoch na ňom môžu zostať.
- Odkaz— pole typu reťazec. Tento atribút uchováva jedinečný identifikátor objektu – GUID. To, čo vidíme v systéme vo vizuálnom zobrazení nazývanom „odkaz“, je len reprezentácia objektu. Nedá sa zmeniť.
- Preddefinované- booleovský typ, zobrazuje, či je prvok preddefinovaný, o tom neskôr. Nedá sa zmeniť.
Záložka "Údaje" tiež uvádza reprezentáciu adresára v systéme, pred verziou 8.2.16 mohol byť reprezentáciou iba kód alebo názov. V najnovších verziách platformy (od 8.3) je možné pohľad popísať nezávisle v module manažéra pomocou obsluhy "ProcessingViewReceivingProcessing".
Číslovanie Tab
Tu môžete zadať nastavenia pre referenciu z hľadiska číslovania. Odporúča sa použiť automatické číslovanie. Kontrola jedinečnosti je príznak, ktorý v prípade potreby pomáha urobiť kód jedinečným. Ak sa s nastaveným príznakom pokúsite zapísať prvok adresára s nejedinečným kódom, dostanete správu v 1C „Kód adresára sa stal nejedinečným“.
Séria kódov – určuje spôsob číslovania adresára, číslovanie adresára môžete zadať v kontexte vlastníka. Napríklad protistrana "Rohy a kopytá" bude mať svoje vlastné číslovanie zmlúv - "1, 2, 3" atď.
Karta Formuláre
Tu sú formuláre pre referenčnú knihu. Ak je konfigurácia spustená v normálnom aj riadenom režime, potom budú predvolene dve karty s formulármi: „hlavný“ a „doplnkový“ — odlišné pre normálnu a riadenú aplikáciu.
Táto stránka má dôležitú referenčnú vlastnosť - "". Ide o veľmi pohodlnú funkciu 1C 8, ktorá umožňuje pri vypĺňaní údajov do vstupného poľa nevstupovať do adresára, ale zadať jeho názov, kód a podobne. a vyberte požadovaný prvok z rozbaľovacieho zoznamu. Vyzerá to takto: 
Iná karta
Na karte môžete získať rýchly prístup k hlavným modulom adresára - objektovému modulu a modulu manažéra.
Môžete tiež definovať zoznam preddefinovaných prvkov vyhľadávania na stránke. Toto sú položky, ktoré nie je možné odstrániť v režime Enterprise. K preddefinovaným prvkom je možné pristupovať priamo v konfigurátore podľa názvu, napríklad: Catalogs.Nomenclature.Service.
Táto záložka tiež definuje režim blokovania – automatický alebo riadený. Používanie fulltextového vyhľadávania, ako aj referenčné informácie o adresári, dostupné v režime 1C: Enterprise.
Ildarovič 6489 16.11.12 18:24 Teraz v téme
() Vladimír! Som rád, že ste článku venovali pozornosť, najmä preto, že ste boli jedným z prvých, ktorí túto techniku videli (a ocenili) v diskusii pred dvoma rokmi "Naozaj napíš záludný dotaz." Neprišiel som na zaujímavú otázku pre seba, ale videl som ju vo fóre. Autorom otázky je Stanislav Sheptalov. Ďalej - 24.10.2012 ten istý (len na to upozornil, keďže prezývka je iná) člen fóra položil podobnú otázku, ale už aplikovanú na hierarchiu. Ukazuje sa, že PRAKTICKÁ otázka je vyriešená. Ďalej som sa v súlade s „vedeckým“ prístupom pozrel na praktické problémy, kde je možné túto techniku použiť. Našlo sa ďalších 7 problémov. 5 - v tomto článku. Medzi nimi je problém o cykloch v špecifikáciách, ktorý som predtým sľúbil vyriešiť Ish_2 jedným dotazom. Myslím, že Ish_2 vás bude môcť presvedčiť o relevantnosti tejto úlohy - strávil na nej veľa času. Riešenie je krátke - z niekoľkých riadkov, preto je mimoriadne zrozumiteľné, formulované neprocedurálnym štýlom, cez požiadavku na výsledok. No a iné úlohy sa plnili v článkoch a na fóre, ponúkali sa pre nich ťažkopádnejšie riešenia. Počkajme si teda, ako často to bude platiť. Takúto spätnú väzbu očakávam od tých, ktorí to vyskúšajú.
Mimochodom, o tom, že tento odbor matematiky nemá ďaleko k praxi a je potrebný pre účtovníkov, svedčí všeobecný modul „Úprava nákladov“ v BP2, na ktorom sa práve fičíme (nestabilná prevádzka bežnej požiadavky). Tam hovoríme o prerušení cyklov grafu pohybov nomenklatúry a zostavení kostry.
Teraz o štruktúre databázy "pre konkrétnu úlohu." Bola položená otázka o implementácii úlohy v 1C, a preto bola úloha vyriešená v 1C. Ak by ste sa vás spýtali „ktorý autobus vás môže odviezť do knižnice“ a odpovedali by ste, že je lepšie letieť vzducholoďou, potom by ste jednoducho nepochopili (možno okrem tých, ktorí uviazli v moskovskej dopravnej zápche) . Spočiatku metóda fungovala v úplne inom jazyku.
Vo všeobecnosti vás nebudem môcť presvedčiť, keď si myslíte, že architektúra platformy 1C nie je dobrá. Môžem len vyjadriť svoj názor. Je drahé vyvinúť databázovú schému od začiatku pre konkrétnu úlohu. Ak to porovnáme s výstavbou: 1C sú panelové výškové budovy - lacné bývanie - prostriedok masovej automatizácie - preplnené, ale neurazené. Jednotlivé organizácie si môžu najať Normana Fostera, aby presne implementoval ich požiadavky. Zvyšok musí použiť lacné hromadné projekty - relačné DBMS s rigidným objektovým modelom. Okrem toho poznám smutnú skúsenosť s používaním Cache vo viacerých projektoch. Očami vývojára nevyzerá všetko vôbec tak ružovo ako teoreticky. Objektový model 1C obstál v skúške časom – „boli vybudované a osídlené obrovské územia“. Navyše sa vyvíja. Nedávno sa objavila technológia externých zdrojov údajov. A ak si niektorá úloha vyžaduje vyššiu reaktivitu (napríklad fakturačné systémy), teraz môžete bezproblémovo pripojiť 1C k inému DBMS. Takto sme napríklad vymenili s importovaným ERP.
Ale napriek tomu by som nerád odvádzal rozhovor od hlavnej témy - práce navrhovaných techník v podrobnom popise PRAKTICKÝCH problémov.
V tejto časti sú uvedené príklady riešenia typických úloh pri práci s hierarchickými adresármi.
Získanie prvkov hierarchického adresára, ktoré sú podriadené danej skupine
Na získanie podriadených prvkov hierarchického adresára poskytuje dopytovací jazyk konštrukciu IN HIERARCHY. Príklad použitia V HIERARCHII:
VYBERTE SI
Nomenclature.Code,
Nomenklatúra.Nákupná cena
OD
V tomto príklade budú načítané všetky položky v adresári Nomenclature, ktoré sú v skupine &Group, vrátane seba samého, jeho podriadených skupín a prvkov patriacich do podriadených skupín.
Ak nás zaujímajú len prvky a skupiny, ktoré sú priamo v danej skupine, tak takéto prvky môžeme získať nastavením podmienky v poli Parent. Príklad:
VYBERTE SI
Nomenclature.Code,
Nomenklatúra Názov AS Názov,
Nomenklatúra.Nákupná cena
OD
Adresár Nomenklatúra AS Nomenklatúra
KDE
Nomenklatúra.Rodič = &Skupina
Takýto dotaz vyberie skupiny a prvky, ktoré sú podriadené skupine s odkazom &Skupina.
Kontrola prítomnosti podriadených prvkov v prvku adresára
Ak chcete skontrolovať prítomnosť podriadených záznamov prvku slovníka, môžete použiť dotaz podobný tomu, ktorý je uvedený:
V tomto príklade je odkaz na prvok, pre ktorý chcete skontrolovať prítomnosť podradených prvkov, zapísaný do parametra dotazu "Parent". Po vykonaní takéhoto dotazu musíte skontrolovať, či je výsledok prázdny. Ak výsledok nie je prázdny, existujú podriadené záznamy. Inak - nie. Príklad:
If Request.Execute().Empty() Then
alert("žiadne záznamy");
Inak
Show("Dostupné záznamy");
Koniec Ak;
Získanie všetkých rodičov prvku
V dopytovacom jazyku neexistujú žiadne špeciálne prostriedky na získanie všetkých rodičov prvku. Na splnenie úlohy môžete použiť hierarchické súčty, ale získanie hierarchických súčtov je optimalizované na zhrnutie veľkého počtu záznamov a nie je veľmi efektívne na získanie rodičov jedného prvku. Pre efektívnejšie vyhľadávanie všetkých rodičovských záznamov prvku sa odporúča prechádzať cez jeho rodičov v malých častiach. Príklad:
CurrentNomenclatureItem = Nomenklatúra položky;
Požiadavka = Nová požiadavka("SELECT
| Nomenklatúra.Rodič,
| Nomenklatúra.Rodič.Rodič,
| Nomenklatúra.Parent.Parent.Parent,
| Nomenklatúra.Parent.Parent.Parent.Parent,
| Nomenklatúra.Rodič.Rodič.Rodič.Rodič.Rodič
| OD
| Adresár Nomenklatúra AS Nomenklatúra
| KDE
| Item.Reference = &CurrentItemItem";
Kým True Loop
Query.SetParameter("CurrentItemItem", CurrentItemItem);
Vysledok = Request.Run();
If Result.Empty() Then
prerušiť;
Koniec Ak;
Výber = Vysledok.Vyber();
Selection.Next();
Pre ColumnNumber = 0 Podľa Result.Columns.Quantity() - 1 slučka
CurrentItemItem = Selection[ColumnNumber];
prerušiť;
Inak
Správa (Aktuálna položka nomenklatúry);
Koniec Ak;
EndCycle;
Ak CurrentItemItem = References.Nomenclature.EmptyReference() Then
prerušiť;
Koniec Ak;
EndCycle;
V tomto príklade sa v okne servisnej správy zobrazia všetci rodičia pre prepojenie uložené v premennej ElementNomenclature. V cykle sa vyberie 5 rodičov odkazu.
Ak je počet úrovní v adresári obmedzený a malý, potom je možné získať všetkých rodičov v jednom dotaze bez slučky.
Výstup hierarchického adresára do zostavy
Ak chcete zobraziť hierarchickú referenčnú knihu v zostave pri zachovaní hierarchie, musíte použiť dotaz podobný tomuto:
VYBERTE SI
Nomenclature.Code,
Nomenklatúra Názov AS Názov,
Nomenklatúra.Nákupná cena
OD
Adresár Nomenklatúra AS Nomenklatúra
TRIEDIŤ PODĽA
Názov HIERARCHIA
Tento dotaz vyberie všetky položky z adresára a zoradí ich hierarchicky. Výsledok bude zoradený podľa názvu s prihliadnutím na hierarchiu.
Aby sa katalógové skupiny umiestnili nad prvky, je potrebné v tomto dotaze nahradiť klauzulu ORDER BY nasledujúcim:
TRIEDIŤ PODĽA
Nomenklatúra Toto je skupina HIERARCHIA.
názov
Výsledok bude stále usporiadaný hierarchicky, ale skupiny sa zobrazia nad prvkami.
Je tiež možné nahradiť doložku ORDER BY doložkou AUTO ORDER. V tomto prípade sa výsledok zoradí podľa nastavenia vyhľadávania, t.j. ak adresár naznačuje, že skupiny by sa mali nachádzať nad prvkami, budú umiestnené vyššie.
Je tiež možné získať hierarchickú štruktúru adresára pomocou súčtov.
VYBERTE SI
Nomenclature.Code,
Nomenklatúra Názov AS Názov,
Nomenklatúra.Nákupná cena
FROM Handbook Nomenklatúra AS Nomenklatúra
KDE
(Nomenclature.ThisGroup = FALSE)
ZORADIŤ PODĽA
Získajte súčty podľa hierarchie
Ak chcete získať súčty podľa hierarchie v dotaze, v klauzule BY TOTALS zadajte kľúčové slovo HIERARCHY po zadaní poľa, podľa ktorého sa budú vypočítavať súčty. Príklad zostavy „Obrat produktu“ s príjmom súčtov podľa hierarchie:
VYBERTE SI
OD
Nomenklatúra HIERARCHIA
V dôsledku tohto dotazu sa vypočítajú súčty nielen pre každú položku, ale aj pre skupiny, do ktorých táto alebo tá položka patrí.
V prípade, že nie sú potrebné súčty podľa prvkov, ale súčty sú potrebné len podľa skupín, musíme v súčtoch použiť konštrukciu LEN HIERARCHIA. Príklad:
VYBERTE SI
Účtovná nomenklatúra Obraty Nomenklatúra AS Nomenklatúra,
Účtovná nomenklatúraObraty.Číselník.Zastupovanie,
Účtovná nomenklatúraObraty.MnožstvoObrat AS MnožstvoObrat
OD
Akumulačný register Účtovníctvo pre nomenklatúru Obraty AS Účtovanie pre nomenklatúrne obraty
VÝSLEDKY AMOUNT (čísloObrat) ZAPNUTÉ
LEN nomenklatúra HIERARCHIA
V dôsledku tohto dotazu budú celkové záznamy len pre skupiny položiek.
Konštrukt „IN THE HIERARCHY“ v dotazoch 1C:Enterprise 8.x umožňuje získať podriadené prvky objektu hierarchickej konfigurácie podľa daného výberu. Dnes v článku zvážime príklad jeho použitia, ako aj akcie platformy na strane DBMS a jej vplyv na výkon.
Použitie
Zoberme si jednoduchý príklad použitia konštrukcie „IN HIERARCHIA“. Pri vykonávaní nasledujúceho dotazu sa pre odovzdanú hodnotu premennej "Odkaz" získajú podriadené prvky hierarchického odkazu "Produkty".
QueryText = " SELECT | Položky . odkaz,| Tovar . Kód dodávateľa |OD| Adresár . Produkty AS Produkty| KDE | Tovar . Odkaz V HIERARCHII (& Odkaz)"
V testovacej databáze obsahuje adresár "Produkty" nasledujúce testovacie údaje:
Obrázok samozrejme nezobrazuje všetky položky adresára. Snímka obrazovky zobrazuje iba štruktúru ukladania údajov v hierarchickom adresári. V referenčnej tabuľke je uložených 10 skupín najvyššej úrovne, z ktorých každá obsahuje 5 vnorených skupín s 200 prvkami.
Vráťme sa k žiadosti o test. Parameter "&Odkaz" dáme odkaz na skupinu "Skupina - 1" (pozri snímku obrazovky vyššie). Potom bude výsledok dopytu vyzerať takto:
Ako vidíme, požiadavka vrátila odkaz na samotnú hornú skupinu (odovzdanú ako parameter), ako aj vnorené skupiny s prvkami v nich. Použitie konštruktu „IN THE HIERARCHY“ teda umožňuje pohodlným spôsobom získať hierarchicky podriadené údaje.
1C: Syntax podnikového a dotazovacieho jazyka klasický SQL v niektorých ohľadoch veľmi podobné. Ale pre výraz „V HIERARCHII“ neexistuje analóg v dopytovacom jazyku SQL, ako napríklad pre výraz dopytovacieho jazyka platformy „B“ existuje podobný operátor SQL „IN“. Preto je práca platformy s DBMS pri použití tohto operátora zaujímavá.
V zákulisí
Tak poďme na to. Napríklad použijeme predtým napísaný dotaz do adresára "Produkty". Budeme analyzovať akcie platformy pre dve situácie:
- Ako parameter "&Referencia" prejdeme skupinou najvyššej úrovne "Skupina 1" (ako sme to urobili predtým).
- V parametri odovzdáme odkaz na skupinu „Skupina 1 – 1“ vnorenú do skupiny najvyššej úrovne „Skupina 1“.
Teraz v poriadku. V prvom prípade platforma vykoná na serveri SQL nasledujúce akcie:
1.
Najprv sa vykoná SQL dotaz, aby sa získal odkaz na referenčnú skupinu odovzdanú ako parameter a všetky skupiny, ktoré sú jej podriadené. Výsledok sa umiestni do dočasnej tabuľky "#tt1". 
2. V druhom kroku sa rovnaký dotaz vykoná dvakrát:
Na snímke obrazovky je text SQL dotazu podrobne komentovaný. Stručne povedané, dotaz vám umožňuje vybrať podriadené prvky pre skupiny, na ktoré sa odkazuje v dočasnej tabuľke. Otázkou zostáva: „Prečo sa dotaz vykonáva dvakrát?“. Tu je odpoveď jednoduchá: najprv dotaz získa podriadené prvky pre skupiny prvej úrovne, ktoré sú už obsiahnuté v dočasnej tabuľke (pozri bod 1). Druhý dotaz potom získa čiastkové prvky pre podskupiny druhej úrovne. Keďže na tretej úrovni hierarchie neexistuje žiadna skupina adresárov, tento dotaz sa už nevykoná.
V našom prípade druhý dotaz vráti prázdny výsledok, pretože neexistujú žiadne podriadené prvky pre záznamy umiestnené na 3. úrovni hierarchie (tam nie je žiadna skupina).
3. Na získanie konečného výsledku dotazu platforma vygeneruje nasledujúci SQL dotaz:
Výsledok tohto konkrétneho dotazu môže byť ďalej spracovaný pomocou algoritmov v jazyku zabudovanom v platforme. Záznamy v dočasnej tabuľke "#tt1" sa teda používajú na nastavenie podmienky výberu z referenčnej tabuľky "_Reference41".
4. V poslednom kroku platforma 1C:Enterprise 8.x vymaže dočasnú tabuľku „#tt1“, pretože sa už v budúcnosti nebude používať.
Tým sa dokončí proces vykonania príkazu „V HIERARCHII“. Dovoľte mi pripomenúť, že uvažovaná postupnosť akcií na serveri SQL bola vykonaná, keď sme do požiadavky na strane platformy odovzdali odkaz skupine najvyššej úrovne „Skupina – 1“. Ako sa však platforma zachová, ak ako parameter „&Odkaz“ odovzdáme odkaz na skupinu druhej úrovne „Skupina – 1 – 1“? Všetko prebehne rovnako, až na nasledujúci moment: vyššie v druhej fáze vykonávania SQL dotazov platformou bolo napísané, že dotaz na získanie podriadených prvkov bol vykonaný dvakrát - v prípade získania podriadených prvkov pre skupina "Skupina - 1 - 1", toto nie je tento prípad. Žiadosť bude vykonaná iba raz.
Faktom je, že počet žiadostí o získanie podriadených prvkov závisí od počtu skupín v hierarchii. Inými slovami, ak úroveň hierarchie prvkov obsahuje aspoň jednu skupinu, potom žiadosť z bodu 2.
Vplyv na výkon
Nesprávne použitie ľubovoľného operátora v dotaze môže viesť k neoptimálnemu výkonu systému. Výnimkou nie je ani uvažovaný operátor „V HIERARCHII“. Musí sa používať opatrne, pretože značne komplikuje algoritmus na vykonávanie SQL dotazov do databázy a tým zvyšuje zaťaženie servera DBMS.
Uvediem príklad neoptimálneho dotazu, ktorý môže viesť k smutným dôsledkom uvedeným vyššie:
VYBERTE produkty. Odkaz z adresára. Produkty AKO Produkty KDE (Produkty. Odkaz V HIERARCHII (& Link) ALEBO Produkty. Odkaz V HIERARCHII (& Link1) ALEBO Produkty. Odkaz V HIERARCHII (& Link2) )
Ako asi tušíte, dotaz povedie k vytvoreniu mnohých SQL dotazov, čo povedie k zníženiu výkonu informačného systému.
Urobte si vlastné závery!
Závery sú na vás. Poviem len, že operátor „V HIERARCHII“ používa platforma pre systém skladania údajov, keď medzi podmienky výberu patria „V SKUPINE“, „V SKUPINE ZO ZOZNAMU“ a iné. Myslím, že nestojí za to vysvetľovať, že pri nesprávnych manipuláciách môžu používatelia vykonať veľmi zložitý výber a niekoľkokrát zvýšiť zaťaženie servera 1C a DBMS. Nastavenia zmeňme len pre pokročilých používateľov.
A samozrejme pri písaní vlastných mechanizmov dávajte pozor na operátor „V HIERARCHII“. Na jednej strane veľmi pohodlné a na druhej nebezpečné.
Čo je to adresár 1s a prečo je potrebný? V adresári sú uložené podmienene konštantné informácie, t.j. informácie, ktoré sa počas dlhého obdobia príliš nemenia. Napríklad referenčná kniha „Nomenklatúra“ obsahuje zoznam predaného alebo vyrobeného tovaru. Adresár môže tiež obsahovať množinu vlastností popisujúcich prvok adresára.
Ak na porovnanie vezmeme pohlavie osoby, potom je zoznam obmedzený a nezmenený, takže je preň vhodnejší zoznam.
Po vytvorení nového adresára uvidíme nasledujúci obrázok.
Zvážte všetky jeho záložky.
Hlavná
Tu zadáte názov (identifikátor v databáze) a synonymum (vlastný názov adresára). Voliteľný je komentár, ktorý môže vysvetľovať účel adresára alebo popisovať jeho vlastnosti.
Hierarchia
Na tejto karte môžete nastaviť hĺbku vnorenia prvkov adresára. Pomocou tohto nastavenia je vhodné ohraničovať a detailovať prvky podľa určitých kritérií. Napríklad produkty „Skrine“ v jednej skupine a produkty „Stoly“ v inej. Štandardne pri vytváraní adresára predstavuje zoznam prvkov. Ak zaškrtnete políčko Hierarchický adresár, potom každý prvok môže byť podriadený inému prvku (skupine). Nižšie sú uvedené možnosti prispôsobenia tejto karty a zmeny zobrazenia v používateľskom režime.
Hierarchický pohľad:
Hierarchia skupín a prvkov
Pri tomto nastavení môže byť vnorenie prvkov iba do skupín (priečinkov).
Ako vidíte, všetky prvky a skupiny majú rovnaké ikony a ľubovoľný prvok možno vnoriť.
Umiestnite skupiny na vrch
Keď je toto políčko začiarknuté, skupiny budú vždy navrchu, inak budú usporiadané v poradí zoradenia, napríklad takto:
Limit úrovne hierarchie
Ak toto políčko nie je začiarknuté, vkladanie je neobmedzené.
Ak je začiarkavacie políčko začiarknuté, nižšie môžete zadať počet úrovní.
Vlastníci
Záložka vlastníkov môžu byť špecifikované ďalšie adresáre, ktorým je tento podriadený. Schéma vzťahov podriadených adresárov je podobná schéme vzťahov hierarchického adresára, len tu iný adresár vystupuje ako nadradený a nazýva sa vlastník. V typických konfiguráciách je dobrým príkladom podriadenie adresára „Contracts“ adresáru „Contractors“, pretože nemôže existovať zmluva, ktorá nepatrí žiadnej protistrane.
V poli "Zoznam vlastníkov adresára" je uvedený zoznam adresárov, do ktorých patria prvky tohto adresára.
Nižšie v poli "Použitie podriadenosti" je uvedené, čomu budú prvky tohto adresára podriadené.
Ako programovo zistiť, či je adresár hierarchický alebo nie
Ak to chcete urobiť, musíte sa pozrieť na metadáta
ThisHierarchicalDirectory = Metadata.Directory.Contractors.Hierarchical;
Pokračovanie nabudúce…