Za prvé, uživatelské rozhraní: jako uživatele nesnáším pro vyhledávání produktu v katalogu organizovaném v přísně hierarchickém způsob. Nikdy si nepamatuji, v jaké pod-pod-pod-pod-kategorii je "exotický" produkt, a to mě nutí ztrácet čas zkoumáním "slibných" kategorií, abych zjistil, že je zařazen do (pro mě alespoň ) podivným způsobem.
Co Kevin Peno navrhuje je dobrá rada a je známá jako fazetované procházení . Jako Marcia Bates napsal v Po tečkované bombě :Získání webových informací v pravý čas , " .. fasetová klasifikace je pro hierarchickou klasifikaci jako relační databáze pro hierarchické databáze. ... ".
."Fasetové vyhledávání v podstatě umožňuje uživatelům prohledávat váš katalog počínaje jakýmkoli „fazetem“, který preferují, a nechat je filtrovat informace výběrem dalších aspektů při vyhledávání. Všimněte si, že na rozdíl od toho, jak jsou systémy značek obvykle koncipovány, nic vám nebrání v hierarchickém uspořádání některých z těchto aspektů.
Chcete-li rychle porozumět tomu, o čem je fasetové vyhledávání, existuje několik ukázek k prozkoumání na Projekt Flamenco Search Interface Project – Search Interfaces that Flow .
Zadruhé, aplikační logika: co Manitra
Navrhuje je také dobrá rada (jak tomu rozumím), tj. oddělení nodes a links stromu/grafu v různých vztazích. To, co nazývá „tabulkou předků“ (což je ovšem mnohem lépe intuitivní název), je známé jako tranzitivní uzávěr orientovaného acyklického grafu (DAG)
(vztah k dosažitelnosti). Kromě výkonu výrazně zjednodušuje dotazy, jak řekl Manitra.
Ale Navrhuji zobrazení pro takovou "tabulku předků" (přechodné uzavření), takže aktualizace jsou v reálném čase a přírůstkové, nikoli periodické pomocí dávkové úlohy. V dokumentech, které jsem zmínil ve své odpovědi na dotazovací jazyk pro sady grafů:otázka datového modelování . Konkrétně se podívejte na Udržování tranzitivního uzavření grafů v SQL (.ps - postscript).
Vztah mezi produkty a kategoriemi
První bod Manitry také stojí za zdůraznění.
Říká, že mezi produkty a kategoriemi existuje vztah mnoho k mnoha. Tzn.:každý produkt může být v jedné nebo více kategoriích a v každé kategorii může být nula nebo více produktů.
Dané relační proměnné (relvary) Produkty a kategorie takový vztah lze reprezentovat například jako relvar PC s alespoň atributy P# a C#, tj. čísly produktů a kategorií (identifikátory) ve vztahu cizího klíče s odpovídajícími Produkty a kategoriemi. čísla.
Toto je doplněk ke správě hierarchií kategorií. Toto je samozřejmě pouze návrhová skica.
Při fasetovém procházení v SQL
Užitečným konceptem pro implementaci „fasetovaného prohlížení“ je relační rozdělení nebo dokonce relační srovnání (viz spodní část odkazované stránky). Tj. rozdělením PC (Produkty-Kategorie) (rostoucím) seznamem kategorií vybraných uživatelem (fazetová navigace) získáte pouze produkty v těchto kategoriích (samozřejmě se předpokládá, že ne kategorie všechny se vzájemně vylučují, jinak výběrem dvou kategorií získá jedna nula produktů).
DBMS založené na SQL obvykle postrádají tyto operátory (dělení a srovnání), takže níže uvádím některé zajímavé články, které je implementují/diskutují:
- ABY JE ODDĚLENÍ VZTAHŮ Srozumitelné (.pdf z index relace FIE 2003 );
- Jednodušší (a lepší) SQL přístup k relačnímu dělení (.pdf z Journal of Information Systems Education - Obsah, svazek 13, číslo 2 (2002) );
- Zpracování častých dotazů na zjišťování sady položek podle operátorů rozdělení a nastavení omezení ;
- Zákony pro přepisování dotazů obsahujících operátory divize ;
- Algoritmy a aplikace pro univerzální kvantifikaci v relačních databázích;
- Optimalizace dotazů s univerzální kvantifikací v objektově orientovaných a Objektově-relační databáze ;
- (vyžadován přístup ACM) O složitosti dělení a spojení množin ve vztahu algebra ;
- (vyžadován přístup ACM) Rychlé algoritmy pro univerzální kvantifikaci ve velkých databázích;
a tak dále...
Nebudu zde zabíhat do podrobností, ale interakce mezi hierarchiemi kategorií a procházením aspektů vyžaduje zvláštní péči.
Odbočka k „plochosti“
Krátce jsem se podíval na článek, na který odkazuje Pras , Správa hierarchických dat v MySQL , ale přestal jsem číst po těchto pár řádcích v úvodu:
Abychom pochopili, proč je toto trvání na plochosti vztahů prostý nesmysl , představte si krychli v trojrozměrném kartézském souřadnicovém systému :bude identifikován 8 souřadnicemi (trojicemi), řekněme P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [zde nás nezajímá omezení na těchto souřadnicích tak, aby ve skutečnosti představovaly krychli].
Nyní tuto sadu souřadnic (body) vložíme do relační proměnné a tuto proměnnou pojmenujeme Points . Budeme zastupovat hodnotu vztahu Points jako tabulka níže:
Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Je tato krychle „zploštěna“ pouhým aktem jejího znázornění tabulkovým způsobem? Je relace (hodnota) to samé jako její tabulková reprezentace?
Relační proměnná předpokládá jako hodnoty množiny bodů v n-rozměrném diskrétním prostoru, kde n je počet relačních atributů ("sloupců"). Co pro n-rozměrný diskrétní prostor znamená být „plochý“? Prostě nesmysl, jak jsem psal výše.
Nechápejte mě špatně, určitě je pravda, že SQL je špatně navržený jazyk a že DBMS založené na SQL jsou plné idiosynkrazií a nedostatků (NULL, redundance, ...), zejména těch špatných, DBMS-as- typ dumb-store (žádná referenční omezení, žádná omezení integrity, ...). Ale to nemá nic společného s relačními datovými modely fantazírovanými omezeními, naopak:čím dál tím víc se od toho odvracejí a horší je výsledek.
Zejména relační datový model, jakmile mu porozumíte, nepředstavuje žádný problém při reprezentaci jakékoli struktury, dokonce i hierarchií a grafů, jak jsem podrobně popsal s odkazy na publikované články uvedené výše. I SQL může, pokud přehlédnete jeho nedostatky, chybět něco lepšího.
Na "modelu vnořené sady"
Přečetl jsem zbytek tohoto článku a takový logický design na mě nijak zvlášť nezapůsobil:navrhuje to prolínat dvě různé entity, uzly a odkazy , do jednoho vztahu a to pravděpodobně způsobí trapas. Ale nechci ten návrh analyzovat důkladněji, omlouvám se.
UPRAVIT: Stephan Eggermont v komentářích níže namítl, že „ Model plochého seznamu je problém. Jde o abstrakci implementace, která ztěžuje dosažení výkonu. ... ".
."A teď mi jde přesně o to, že:
- tento „model s plochým seznamem“ je fantasy :to, že jeden rozloží (reprezentuje) vztahy jako tabulky ("ploché seznamy") neznamená, že vztahy jsou "prosté seznamy" ("objekt" a jeho reprezentace nejsou totéž);
- logická reprezentace (vztah) a podrobnosti fyzického úložiště (horizontální nebo vertikální rozklady, komprese, indexy (haše, b+strom, r-strom, ...), shlukování, dělení atd.) jsou odlišné; jeden z bodů relačního datového modelu (RDM ) je oddělení logického od „fyzického“ modelu (s výhodami pro uživatele i implementátory DBMS);
- výkon je přímým důsledkem podrobností o fyzickém úložišti (implementace), a ne logické reprezentace (Eggermontův komentář je klasickým příkladem logicko-fyzikálního zmatku ).
RDM model nijak neomezuje implementace; člověk může volně implementovat n-tice a vztahy, jak uzná za vhodné. Vztahy nemusí být nutně soubory a n-tice nemusí být nutně záznamy o souboru. Taková korespondence je hloupá implementace přímého obrázku .
Bohužel implementace DBMS založené na SQL jsou , příliš často hloupé implementace přímého obrazu a trpí špatným výkonem v různých scénářích - OLAP /ETL existují produkty, které tyto nedostatky pokrývají.
To se pomalu mění. Existují komerční a svobodné softwarové/open source implementace, které se konečně vyhnou tomuto zásadnímu úskalí:
- Vertica , která je komerčním nástupcem..
- C-Store:sloupcově orientovaný DBMS ;
- MonetDB ;
- LucidDB ;
- Kdb svým způsobem;
- tak dále...
Jde samozřejmě o to ne že musí existovat „optimální“ návrh fyzického úložiště, ale že jakýkoli návrh fyzického úložiště může být abstrahován pěkným deklarativním jazykem založené na relační algebře/kalkulech (a SQL je špatné příklad) nebo více přímo v logickém programovacím jazyce (jako je například Prolog - viz moje odpověď na "převodník prologu na SQL " otázka). Dobrým DBMS by měla být změna designu fyzického úložiště za běhu na základě statistik přístupu k datům (a/nebo uživatelských rad).
A konečně v Eggermontově komentáři je uvedeno prohlášení „ Relační model se stlačuje mezi cloud a prevayler. “ je další nesmysl, ale nemohu to vyvrátit, tento komentář je již příliš dlouhý.