For det første brugergrænsefladen: som bruger hader at søge efter et produkt i et katalog organiseret i et strengt hierarkisk vej. Jeg husker aldrig i hvilken under-under-under-under...-kategori et "eksotisk" produkt er i, og det tvinger mig til at spilde tid på at udforske "lovende" kategorier bare for at opdage, at det er kategoriseret i en (i det mindste for mig ) mærkelig måde.
Hvad Kevin Peno foreslår er et godt råd og er kendt som facetteret browsing . Som Marcia Bates skrev i After the Dot-Bomb :Sådan får du ret til hentning af webinformation , " .. facetteret klassificering er til hierarkisk klassifikation, som relationelle databaser er til hierarkiske databaser. .. ".
I bund og grund giver facetteret søgning brugere mulighed for at søge i dit katalog fra den "facet", de foretrækker, og lade dem filtrere information ved at vælge andre facetter i søgningen. Bemærk, at i modsætning til hvordan tagsystemer normalt opfattes, er der intet, der forhindrer dig i at organisere nogle af disse facetter hierarkisk.
For hurtigt at forstå, hvad facetteret søgning handler om, er der nogle demoer at udforske på The Flamenco Search Interface Project - Search Interfaces that Flow .
For det andet applikationslogikken: hvad Manitra
foreslår er også et godt råd (som jeg forstår det), dvs. adskille nodes og links af et træ/graf i forskellige relationer. Det, han kalder "forfædrebord" (som dog er et meget bedre intuitivt navn) er kendt som transitiv lukning af en rettet acyklisk graf (DAG)
(tilgængelighedsrelation). Ud over ydeevnen forenkler det forespørgsler meget, som Manitra sagde.
Men Jeg foreslår en visning for en sådan "forfædretabel" (transitiv lukning), således at opdateringer er i realtid og trinvise, ikke periodiske ved et batchjob. Der er SQL-kode (men jeg tror, den skal tilpasses lidt til specifikke DBMS'er) i papirer, jeg nævnte i mit svar til forespørgselssprog for grafsæt:datamodelleringsspørgsmål . Se især på Opretholdelse af transitiv lukning af grafer i SQL (.ps - efterskrift).
Produkt-kategori-forhold
Det første punkt i Manitra er også værd at fremhæve.
Det, han siger, er, at mellem produkter og kategorier er der et mange-til-mange forhold. Dvs.:hvert produkt kan være i en eller flere kategorier, og i hver kategori kan der være nul eller flere produkter.
Givet relationsvariable (relvars) Produkter og kategorier en sådan relation kan for eksempel repræsenteres som en relvar PC med mindst attributterne P# og C#, dvs. produkt- og kategorinumre (identifikatorer) i en fremmednøgle relationer med tilsvarende produkter og kategorier tal.
Dette er et supplement til styringen af kategoriernes hierarkier. Dette er selvfølgelig kun en designskitse.
Om facetteret browsing i SQL
Et nyttigt koncept til at implementere "facetteret browsing" er relationel opdeling , eller endda relationelle sammenligninger (se nederst på linket side). dvs. ved at dividere PC (Produkter-Kategorier) med en (voksende) liste over kategorier valgt fra en bruger (facetnavigation) opnår man kun produkter i sådanne kategorier (naturligvis formodes kategorier ikke alt udelukker hinanden, ellers vil valg af to kategorier, den ene opnå nul produkter).
SQL-baseret DBMS mangler normalt disse operatorer (opdeling og sammenligninger), så jeg giver nedenfor nogle interessante artikler, der implementerer/diskuterer dem:
- OM AT GØRE RELATIONEL INDDELING FORSTÅLIG (.pdf fra FIE 2003 Session Index );
- En enklere (og bedre) SQL-tilgang til relationel opdeling (.pdf fra Journal of Information Systems Education - Contents Volume 13, Number 2 (2002) );
- Behandling af hyppige genstandsforespørgsler efter opdeling og sæt indeslutning join-operatører ;
- Love for omskrivning af forespørgsler, der indeholder divisionsoperatører ;
- Algorithmer og applikationer til universel kvantificering i relationelle databaser;
- Optimering af forespørgsler med universel kvantificering i objektorienteret og Objekt-relationelle databaser ;
- (ACM-adgang påkrævet) Om kompleksiteten af division og sæt joins i de relationelle algebra ;
- (ACM-adgang påkrævet) Hurtige algoritmer til universel kvantificering i store databaser;
og så videre...
Jeg vil ikke gå i detaljer her, men interaktion mellem kategorihierarkier og facet-browsing kræver særlig omhu.
En digression om "fladhed"
Jeg kiggede kort på artiklen linket til af Pras , Håndtering af hierarkiske data i MySQL , men jeg stoppede med at læse efter disse få linjer i indledningen:
At forstå hvorfor denne insisteren på fladhed i relationer er bare nonsens , forestil dig en terning i et tredimensionelt kartesisk koordinatsystem :det vil blive identificeret med 8 koordinater (tripletter), f.eks. P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [her er vi ikke bekymrede over begrænsninger på disse koordinater, så de virkelig repræsenterer en terning].
Nu vil vi sætte disse sæt af koordinater (punkter) i en relationsvariabel, og vi vil navngive denne variabel Points . Vi vil repræsentere relationsværdien af Points som en tabel nedenfor:
Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Bliver denne terning "fladet ud" blot ved at repræsentere den på en tabelform? Er en relation (værdi) det samme som dens tabelformede repræsentation?
En relationsvariabel antager som værdier sæt af punkter i et n-dimensionelt diskret rum, hvor n er antallet af relationsattributter ("kolonner"). Hvad betyder det for et n-dimensionelt diskret rum at være "fladt"? Bare noget pjat, som jeg skrev ovenfor.
Misforstå mig ikke, det er helt sikkert rigtigt, at SQL er et dårligt designet sprog, og at SQL-baserede DBMS'er er fulde af idiosynkrasier og mangler (NULL'er, redundans, ...), især de dårlige, DBMS-som- dumb-store type (ingen referencemæssige begrænsninger, ingen integritetsbegrænsninger, ...). Men det har intet at gøre med relationelle datamodellers fantaserede begrænsninger, tværtimod:mere vender de sig væk fra det og værre er resultatet.
Især den relationelle datamodel, når du først forstår den, udgør ikke noget problem med at repræsentere en hvilken som helst struktur, selv hierarkier og grafer, som jeg detaljerede med referencer til publicerede artikler nævnt ovenfor. Selv SQL kan, hvis du udvisker dens mangler, gå glip af noget bedre.
På "The Nested Set Model"
Jeg har skimmet resten af denne artikel og jeg er ikke specielt imponeret over sådan et logisk design:det foreslår at forvirre to forskellige entiteter, knudepunkter og links , i én relation, og dette vil sandsynligvis forårsage akavethed. Men jeg er ikke tilbøjelig til at analysere det design mere grundigt, undskyld.
EDIT: Stephan Eggermont protesterede i kommentarerne nedenfor, at " Den flade liste-model er et problem. Det er en abstraktion af implementeringen, der gør det vanskeligt at opnå ydeevne. ... ".
Nu er min pointe, netop, at:
- denne "fladlistemodel" er en fantasi :bare fordi man udlægger (repræsenterer) relationer som tabeller ("flade lister"), betyder det ikke, at relationer er "flade lister" (et "objekt" og dets repræsentationer er ikke det samme);
- en logisk repræsentation (relation) og fysiske lagringsdetaljer (horisontale eller lodrette dekomponeringer, komprimering, indekser (hashes, b+træ, r-træ, ...), klyngedannelse, partitionering osv.) er forskellige; et af punkterne i relationel datamodel (RDM ) er at afkoble logisk fra "fysisk" model (med fordele for både brugere og implementere af DBMS'er);
- ydeevne er en direkte konsekvens af fysiske lagerdetaljer (implementering) og ikke af logisk repræsentation (Eggermonts kommentar er et klassisk eksempel på logisk-fysisk forvirring ).
RDM-modellen begrænser ikke implementeringer på nogen måde; man er fri til at implementere tupler og relationer, som man finder passende. Relationer er ikke nødvendigvis filer og tupler er ikke nødvendigvis registreringer af en fil. Sådan korrespondance er en dum direkte billedimplementering .
Desværre er SQL-baserede DBMS-implementeringer , alt for ofte dumme direkte-image-implementeringer, og de lider under dårlig ydeevne i en række forskellige scenarier - OLAP /ETL produkter findes for at dække disse mangler.
Dette ændrer sig langsomt. Der er kommercielle og gratis software/open source-implementeringer, der endelig undgår denne grundlæggende faldgrube:
- Vertica , som er en kommerciel efterfølger af..
- C-Store:A Column-Oriented DBMS ;
- MonetDB ;
- LucidDB ;
- Kdb på en måde;
- og så videre...
Selvfølgelig er pointen ikke at der skal eksistere et "optimalt" fysisk lagerdesign, men at uanset fysisk lagerdesign kan abstraheres væk af et pænt deklarativt sprog baseret på relationel algebra/calculi (og SQL er en dårlig eksempel) eller mere direkte på et logisk programmeringssprog (som Prolog, for eksempel - se mit svar til "prolog til SQL-konverter " spørgsmål). Et godt DBMS bør ændre fysisk lagerdesign på farten, baseret på dataadgangsstatistikker (og/eller brugertip).
Til sidst i Eggermonts kommentar erklæringen " Den relationelle model er ved at blive klemt mellem skyen og prevayler. " er endnu et vrøvl, men jeg kan ikke give en afvisning her, denne kommentar er allerede for lang.