Råd om databasstruktur behövs

Först, användargränssnittet: som användare hatar att söka efter en produkt i en katalog organiserad i en strängt hierarkisk sätt. Jag kommer aldrig ihåg i vilken sub-sub-sub-sub...-kategori en "exotisk" produkt är i och detta tvingar mig att slösa tid på att utforska "lovande" kategorier bara för att upptäcka att den är kategoriserad i en (för mig, åtminstone ) konstigt sätt.

Vad Kevin Peno föreslår är ett bra råd och är känt som facetterad surfning . Som Marcia Bates skrev i After the Dot-Bomb :Att få webbinformation rätt den här gången , " .. facetterad klassificering är till hierarkisk klassificering som relationsdatabaser är till hierarkiska databaser. .. ".

I huvudsak tillåter facetterad sökning användare att söka i din katalog utifrån vilken "facet" de föredrar och låta dem filtrera information genom att välja andra aspekter längs sökningen. Observera att, i motsats till hur taggsystem vanligtvis uppfattas, är det inget som hindrar dig från att organisera vissa av dessa aspekter hierarkiskt.

För att snabbt förstå vad facetterad sökning handlar om finns det några demos att utforska på The Flamenco Search Interface Project - Search Interfaces that Flow .

För det andra, applikationslogiken: vad Manitra föreslår är också ett bra råd (som jag förstår det), d.v.s. att separera nodes och links av ett träd/graf i olika relationer. Det han kallar "förfädertabell" (som dock är ett mycket bättre intuitivt namn) är känt som transitiv stängning av en riktad acyklisk graf (DAG) (nåbarhetsrelation). Utöver prestanda förenklar det frågorna avsevärt, som Manitra sa.

Men Jag föreslår en vy för sådan "förfädertabell" (transitiv stängning), så att uppdateringar sker i realtid och inkrementella, inte periodiska av ett batchjobb. Det finns SQL-kod (men jag tror att den behöver anpassas lite till specifika DBMS) i artiklar som jag nämnde i mitt svar till frågespråk för grafuppsättningar:datamodelleringsfråga . Titta särskilt på Underhålla transitiv stängning av grafer i SQL (.ps - efterskrift).

Produkt-kategoriförhållande

Den första punkten i Manitra är också värd att betona.

Vad han säger är att det mellan produkter och kategorier finns ett många-till-många-förhållande. Dvs:varje produkt kan finnas i en eller flera kategorier och i varje kategori kan det finnas noll eller flera produkter.

Givna relationsvariabler (relvars) Produkter och kategorier ett sådant samband kan till exempel representeras som en relvar PC med åtminstone attributen P# och C#, dvs. produkt- och kategorinummer (identifierare) i en främmande nyckelrelationer med motsvarande produkter och kategorier siffror.

Detta är ett komplement till hanteringen av kategoriernas hierarkier. Naturligtvis är detta bara en designskiss.

Om facetterad surfning i SQL

Ett användbart koncept för att implementera "facetterad surfning" är relationsindelning , eller till och med relationella jämförelser (se längst ner på länkad sida). d.v.s. genom att dela PC (Produkter-Kategorier) med en (växande) lista med kategorier vald från en användare (facettnavigering) får man endast produkter i sådana kategorier (naturligtvis antas kategorier inte alla ömsesidigt utesluter, annars får du noll produkter om du väljer två kategorier.

SQL-baserade DBMS saknar vanligtvis dessa operatorer (uppdelning och jämförelser), så jag ger nedan några intressanta artiklar som implementerar/diskuterar dem:

• OM ATT GÖRA RELATIONELL INDELNING BEGRÄNSLIG (.pdf från FIE 2003 Session Index );
• En enklare (och bättre) SQL-metod för relationsindelning (.pdf från Journal of Information Systems Education - Contents Volume 13, Number 2 (2002) );
• Bearbetning av frekventa sökfrågor för upptäckt av objektuppsättningar efter division och uppsättningsinneslutning join-operatorer ;
• Lagar för omskrivning av frågor som innehåller divisionsoperatörer ;
• Algorithms and Applications for Universal Quantification in Relational Databases;
• Optimera frågor med universell kvantifiering i objektorienterad och Objektrelationella databaser ;
• (ACM-åtkomst krävs) Om komplexiteten i divisions- och uppsättningskopplingar i de relationella algebra ;
• (ACM-åtkomst krävs) Snabba algoritmer för universell kvantifiering i stora databaser;

och så vidare...

Jag kommer inte att gå in på detaljer här men interaktion mellan kategorihierarkier och facettsurfning kräver särskild omsorg.

En utvikning om "platthet"

Jag tittade kort på artikeln länkad av Pras , Hantera hierarkisk data i MySQL , men jag slutade läsa efter dessa få rader i inledningen:

Att förstå varför denna insisterande på flathet i relationer är bara nonsens , föreställ dig en kub i ett tredimensionellt kartesiskt koordinatsystem :det kommer att identifieras med 8 koordinater (tripletter), säg P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [här är vi inte bekymrade över begränsningar på dessa koordinater så att de verkligen representerar en kub].

Nu kommer vi att lägga dessa uppsättningar av koordinater (punkter) i en relationsvariabel och vi kommer att namnge denna variabel Points . Vi kommer att representera relationsvärdet för Points som en tabell nedan:

Points|  x |  y |  z |
=======+====+====+====+
       | x1 | y1 | z1 |
       +----+----+----+
       | x2 | y2 | z2 |
       +----+----+----+
       | .. | .. | .. |
       | .. | .. | .. |
       +----+----+----+
       | x8 | y8 | z8 |
       +----+----+----+

Blir denna kub "tillplattad" bara genom att representera den på ett tabellformigt sätt? Är en relation (värde) samma sak som dess tabellrepresentation?

En relationsvariabel antar som värden uppsättningar av punkter i ett n-dimensionellt diskret utrymme, där n är antalet relationsattribut ("kolumner"). Vad betyder det att ett n-dimensionellt diskret utrymme är "platt"? Bara nonsens, som jag skrev ovan.

Missförstå mig rätt, det är verkligen sant att SQL är ett dåligt designat språk och att SQL-baserade DBMS:er är fulla av egenheter och brister (NULLs, redundans, ...), speciellt de dåliga, DBMS-som- dumb-store-typ (inga referensbegränsningar, inga integritetsbegränsningar, ...). Men det har ingenting att göra med fantiserade begränsningar av relationsdatamodellen, tvärtom:mer vänder de sig bort från det och värre är resultatet.

I synnerhet utgör den relationella datamodellen, när du väl förstår den, inga problem med att representera vilken struktur som helst, till och med hierarkier och grafer, som jag beskrev med hänvisningar till publicerade artiklar som nämns ovan. Även SQL kan missa något bättre, om du spolar över dess brister.

På "The Nested Set Model"

Jag skummade resten av den artikeln och jag är inte särskilt imponerad av en sådan logisk design:den föreslår att man ska blanda ihop två olika enheter, noder och länkar , till en relation och detta kommer förmodligen att orsaka besvärlighet. Men jag är inte benägen att analysera den designen mer ingående, tyvärr.

EDIT: Stephan Eggermont invände, i kommentarerna nedan, att " Den platta listmodellen är ett problem. Det är en abstraktion av implementeringen som gör prestanda svår att uppnå. ... ".

Nu är min poäng just att:

1. denna "platta listmodell" är en fantasi :bara för att man lägger ut (representerar) relationer som tabeller ("platta listor") betyder det inte att relationer är "platta listor" (ett "objekt" och dess representationer är inte samma sak);
2. en logisk representation (relation) och fysiska lagringsdetaljer (horisontella eller vertikala nedbrytningar, komprimering, index (hash, b+träd, r-träd, ...), klustring, partitionering, etc.) är distinkta; en av punkterna i relationsdatamodellen (RDM ) är att frikoppla logisk från "fysisk" modell (med fördelar för både användare och implementerare av DBMS);
3. prestanda är en direkt konsekvens av fysisk lagringsinformation (implementering) och inte av logisk representation (Eggermonts kommentar är ett klassiskt exempel på logisk-fysisk förvirring ).

RDM-modellen begränsar inte implementeringar på något sätt; man är fri att implementera tupler och relationer som man vill. Relationer är inte nödvändigtvis filer och tupler är inte nödvändigtvis register över en fil. Sådan korrespondens är en dum direkt-bildimplementering .

Tyvärr är SQL-baserade DBMS-implementationer , alltför ofta, dumma implementeringar av direkta bilder och de har dålig prestanda i en mängd olika scenarier - OLAP /ETL produkter finns för att täcka dessa brister.

Detta håller långsamt på att förändras. Det finns kommersiella och fri programvara/öppen källkod implementeringar som slutligen undviker denna grundläggande fallgrop:

• Vertica , som är en kommersiell efterföljare till...
• C-Store:A Column-Oriented DBMS ;
• MonetDB ;
• LucidDB ;
• Kdb på ett sätt;
• och så vidare...

Självklart är poängen inte att det måste finnas en "optimal" fysisk lagringsdesign, men att vilken fysisk lagringsdesign som helst kan abstraheras bort med ett trevligt deklarativt språk baserat på relationalgebra/kalkyl (och SQL är en dålig exempel) eller mer direkt på ett logiskt programmeringsspråk (som Prolog, till exempel - se mitt svar på "prolog till SQL-konverterare " fråga). Ett bra DBMS bör ändra fysisk lagringsdesign direkt, baserat på dataåtkomststatistik (och/eller användartips).

Slutligen, i Eggermonts kommentar uttalandet " Den relationella modellen håller på att klämmas mellan molnet och prevayler. " är ett annat nonsens men jag kan inte ge ett vederläggande här, den här kommentaren är redan för lång.