Navrh architektury rubrika: Programování: Jiné
2
Jaroslav Urban
Zdravim,
hledam pomoc ohledne architektury jednoho business pripadu.
pracujeme, zjednodusene, na IT systemu pro evidenci nekolika entit (user, device, files, ...) kazda tato entita ma nejake metadata pricemz nektera se prolinaji mezi entitami. Napr. lokace, spolecnost. Pod metadaty si predstavuji prevazne atributy, ale mozna se do toho muze jeste michat treba chovani, pokud to lze chapat jinak?
Na zaklade kombinace nekolika metadat se maji pak provadet nejake akce. Napr. posli soubor A do vsech device v lokaci A. Nebo Vsem users z lokace B povol pristup na reporty typu A, B, C.
Situace se komplikuje tim, ze ty metadata muzou mit i hirearchii, napr. pro Device A - lokace Praha > Praha 4 > Penkavova, Device B - Praha > Praha 4 > Kosmonautu. Takze vyberem Praha 4 vyhovuje podmince 2 device.
Cele to ma byt rychle, flexibilni a pokud mozno jednoduche, heh.
Tak a ted babo rad. Priznam se ze s teorii stromu, nodu a podobnych veci jsem vysel znacne ze cviku. Moje zkusenosti jsou prevazne na relacnich db, tak nedokazu posoudit jestli ma/nema smysl do toho zatahovat nodb. Kolo bylo jiz vymysleno, tak se pro jistotu ptam.
Osobne jsem si predstavoval zhruba toto (relation db only):
1) v podstate mit tabulku pro ulozeni vazeb, tedy ulozeni vazby dvou nodu s nazvem vazby, napr. City > Area ale napriklad taky Praha > Shop A
- NodeID, Parent, Child, Name
2) druha tabulka by byla pak vazba na entitu s hodnotami, kazdy typ entity by mel asi svoji vazebni tabulku -
EntityId, NodeID, Value
- Z #1 by sli stavet ty stromy pro zobrazeni
- z #2 by by pak sli doplnovat hodnoty pro specifickou vazbu a entitu
- vyhledavani by bylo vcelku rychle, vetsina by sla pres PK a indexovane pole hodnot
- ted nevim jak by se resil typ pole hodnoty, string?
Co na to noDb odbornici, ci zahradkari? Jakykoliv tip vitan. Dekuji.
P.S> jedeme na .Net s budouci, pravdepodobnou, migraci do Azure
6
kohven
Pokud se nebude příliš často vkládat a chtěl bych použít jen konvenční technologie, zvážil bych traverzování kolem stromu. https://www.zdrojak.cz/clanky/ukladame-hierarchicka-data-v-databazi-ii/
Komentáře
-
harrison314
:
Ked uz tak aspon s vyuzitim CTE.
—
28.6.2016
-
kohven
:
To traverzování se právě dělá pro to, abych se rekurzi co nejvíce vyhnul. [s]Samozřejmě když chci vypsat cestu k uzlu, tak se bez rekurze neobejdu, ale[/s] když chci všechny uzly v libovolné hloubce pod (nebo nad) daným uzlem, tak si vystačím s jednoduchým dotazem ze SQL ANSI 92. Ale nebylo to myšleno tak, že mám něco proti CTE. Když už musím řešit rekurzi, tak je to určitě lepší než kurzory nebo temp tabulka s while. Ještě k tomu traverzování: má to svoje úskalí. Když budu chtít 100x vkládat nejlevější list do stromu o statisících uzlech, tak update v insert triggeru není ten nejlepší nápad a je potřeba to traverzování řešit jinak a jindy, atd... Ale to si v případě zájmu každý dohledá sám. Není to výmysl posledního měsíce.
—
2.7.2016
-
harrison314
:
No tieto spominane veci riesi v MS SQL index pre hierarchcke data (v mojom poste), pokial chce clovek zgrupovat tak v tom pripade CTE. Ja s vami suhlasim, ale pokial je moznost treba vyuzit veci na to priamo vstavane a urcene.
—
28.6.2016
-
tomas.fejfar
:
"když chci vypsat cestu k uzlu, tak se bez rekurze neobejdu" WHERE lft < :node_lft AND rgt > :node_rgt ORDER BY lft - vrátí cestu od kořene k nodu, bez rekurze IMO
—
1.7.2016
-
kohven
:
@tomas.fejfar: máš pravdu
—
2.7.2016
Pro zobrazení všech 3 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře