Mysql
 sql >> Datenbank >  >> RDS >> Mysql

Beratung zur Datenbankstruktur erforderlich

Zunächst die Benutzeroberfläche: als Benutzer hasse ich um ein Produkt in einem Katalog zu suchen, der streng hierarchisch organisiert ist Weg. Ich erinnere mich nie, in welcher Sub-Sub-Sub-Sub-Kategorie ein "exotisches" Produkt ist, und dies zwingt mich, Zeit damit zu verschwenden, "vielversprechende" Kategorien zu erkunden, nur um herauszufinden, dass es in eine (zumindest für mich) kategorisiert ist ) seltsame Weise.

Was Kevin Peno schlägt vor, ist ein guter Rat und bekannt als Faceted Browsing . Als Marcia Bates schrieb in After the Dot-Bomb :Diesmal den richtigen Abruf von Webinformationen , " .. facettierte Klassifikation verhält sich zur hierarchischen Klassifikation wie relationale Datenbanken zu hierarchischen Datenbanken. .. ".

Im Wesentlichen ermöglicht die facettierte Suche Benutzern, Ihren Katalog ausgehend von der von ihnen bevorzugten "Facette" zu durchsuchen und Informationen zu filtern, indem sie andere Facetten entlang der Suche auswählen. Beachten Sie, dass Sie im Gegensatz zur üblichen Konzeption von Tag-Systemen nichts daran hindert, einige dieser Facetten hierarchisch zu organisieren.

Um schnell zu verstehen, worum es bei der Facettensuche geht, gibt es einige Demos zu erkunden unter The Flamenco Search Interface Project - Search Interfaces that Flow .

Zweitens die Anwendungslogik: was Manitra schlägt ist auch ein guter Rat (so wie ich es verstehe), dh das Trennen von nodes und links eines Baums/Graphen in verschiedenen Relationen. Was er „Ahnentabelle“ nennt (was jedoch ein viel besserer intuitiver Name ist) ist als bekannt transitiver Abschluss eines gerichteten azyklischen Graphen (DAG) (Erreichbarkeitsbeziehung). Abgesehen von der Leistung vereinfacht es Abfragen erheblich, wie Manitra sagte.

Aber Ich schlage eine Ansicht vor für eine solche "Vorfahrentabelle" (transitive Schließung), sodass Aktualisierungen in Echtzeit und inkrementell erfolgen, nicht periodisch durch einen Batch-Job. Es gibt SQL-Code (aber ich denke, er muss ein wenig an bestimmte DBMS angepasst werden) in Papieren, die ich in meiner Antwort auf Abfragesprache für Graphsets:Frage zur Datenmodellierung . Sehen Sie sich insbesondere Maintaining Transitive Closure of Graphs an in SQL (.ps - Postscript).

Beziehung zwischen Produkten und Kategorien

Der erste Punkt von Manitra ist ebenfalls hervorzuheben.

Was er sagt, ist, dass zwischen Produkten und Kategorien eine Viele-zu-Viele-Beziehung besteht. D.h. jedes Produkt kann in einer oder mehreren Kategorien sein und in jeder Kategorie kann es null oder mehr Produkte geben.

Bei gegebenen Beziehungsvariablen (Relvars) Produkten und Kategorien kann eine solche Beziehung beispielsweise als Relvar PC mit mindestens den Attributen P# und C#, d. h. Produkt- und Kategorienummern (Identifikatoren) in einer Fremdschlüsselbeziehung mit entsprechenden Produkten und Kategorien dargestellt werden Nummern.

Dies ergänzt die Verwaltung von Kategorienhierarchien. Dies ist natürlich nur eine Entwurfsskizze.

Über facettiertes Browsen in SQL

Ein nützliches Konzept zum Implementieren von "Faceted Browsing" ist relational division , oder sogar relationale Vergleiche (siehe unten auf der verlinkten Seite). D.h. Durch Teilen von PC (Produkte-Kategorien) durch eine (wachsende) Liste von Kategorien, die von einem Benutzer ausgewählt wurden (Facettennavigation), erhält man nur Produkte in solchen Kategorien (natürlich werden Kategorien nicht vorausgesetzt alle schließen sich gegenseitig aus, andernfalls erhält man null Produkte, wenn man zwei Kategorien wählt).

SQL-basierten DBMS fehlen normalerweise diese Operatoren (Division und Vergleiche), daher gebe ich unten einige interessante Artikel, die sie implementieren/erörtern:

und so weiter...

Ich werde hier nicht ins Detail gehen, aber die Interaktion zwischen Kategoriehierarchien und Facetten-Browsing erfordert besondere Sorgfalt.

Ein Exkurs zum Thema "Ebenheit"

Ich habe mir kurz den von Pras verlinkten Artikel angeschaut , Hierarchische Daten in MySQL verwalten , aber ich habe nach diesen paar Zeilen in der Einleitung aufgehört zu lesen:

Zu verstehen, warum dieses Beharren auf Flachheit der Beziehungen einfach Unsinn ist , stellen Sie sich einen Würfel in einem dreidimensionalen kartesischen Koordinatensystem vor :Es wird durch 8 Koordinaten (Tripletts) identifiziert, sagen wir P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [hier geht es uns nicht darum Beschränkungen für diese Koordinaten, damit sie wirklich einen Würfel darstellen].

Nun werden wir diesen Satz von Koordinaten (Punkten) in eine Beziehungsvariable einfügen und diese Variable Points nennen . Wir werden repräsentieren der Beziehungswert von Points als Tabelle unten:

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

Wird dieser Würfel durch die bloße tabellarische Darstellung "abgeflacht"? Ist eine Relation (Wert) dasselbe wie ihre tabellarische Darstellung?

Eine Beziehungsvariable nimmt als Werte Mengen von Punkten in einem n-dimensionalen diskreten Raum an, wobei n die Anzahl der Beziehungsattribute ("Spalten") ist. Was bedeutet es für einen n-dimensionalen diskreten Raum, "flach" zu sein? Einfach Unsinn, wie ich oben geschrieben habe.

Verstehen Sie mich nicht falsch, es ist sicherlich wahr, dass SQL eine schlecht designte Sprache ist und dass SQL-basierte DBMS voller Eigenheiten und Mängel sind (NULLs, Redundanz, ...), besonders die schlechten, die DBMS-as- Dumb-Store-Typ (keine referenziellen Einschränkungen, keine Integritätseinschränkungen, ...). Das hat aber nichts mit phantasierten Einschränkungen relationaler Datenmodelle zu tun, im Gegenteil:Je mehr sie sich davon abwenden, desto schlimmer ist das Ergebnis.

Insbesondere stellt das relationale Datenmodell, sobald Sie es verstanden haben, kein Problem dar, beliebige Strukturen darzustellen, sogar Hierarchien und Graphen, wie ich mit Verweisen auf die oben erwähnten veröffentlichten Artikel ausführlich beschrieben habe. Sogar SQL kann, wenn man seine Mängel beschönigt, etwas Besseres verpassen.

Auf dem "Modell der verschachtelten Menge"

Ich habe den Rest von dieses Artikels überflogen und ich bin nicht besonders beeindruckt von solch einem logischen Design:Es schlägt vor, zwei verschiedene Entitäten, Knoten, durcheinander zu bringen und Links , in eine Beziehung, und dies wird wahrscheinlich zu Unbeholfenheit führen. Aber ich bin nicht geneigt, dieses Design gründlicher zu analysieren, tut mir leid.

BEARBEITEN: Stephan Eggermont wandte in den Kommentaren unten ein, dass " Das flache Listenmodell ein Problem ist. Es ist eine Abstraktion der Implementierung, die es schwierig macht, Leistung zu erzielen. ... ".

Nun, mein Punkt ist genau das:

  1. dieses "flache Listenmodell" ist eine Fantasie :Nur weil man Relationen als Tabellen ("flache Listen") anlegt (repräsentiert), heißt das nicht, dass Relationen "flache Listen" sind (ein "Objekt" und seine Repräsentationen sind nicht dasselbe);
  2. eine logische Darstellung (Relation) und physische Speicherdetails (horizontale oder vertikale Zerlegung, Komprimierung, Indizes (Hashes, b+tree, r-tree, ...), Clustering, Partitionierung usw.) sind unterschiedlich; einer der Punkte des relationalen Datenmodells (RDM ) besteht darin, das logische vom "physischen" Modell zu entkoppeln (mit Vorteilen für Benutzer und Implementierer von DBMSes);
  3. Leistung ist eine direkte Folge von physischen Speicherdetails (Implementierung) und nicht der logischen Repräsentation (Eggermonts Kommentar ist ein klassisches Beispiel für logisch-physikalische Verwirrung ). ).

Das RDM-Modell schränkt Implementierungen in keiner Weise ein; man ist frei, Tupel und Relationen zu implementieren, wie man es für richtig hält. Beziehungen sind nicht unbedingt Dateien und Tupel sind nicht unbedingt Aufzeichnungen einer Datei. Eine solche Korrespondenz ist eine dumme direkte Bildimplementierung .

Leider sind SQL-basierte DBMS-Implementierungen , zu oft dumme Direktbild-Implementierungen und sie leiden in einer Vielzahl von Szenarien unter schlechter Leistung - OLAP /ETL Es gibt Produkte, um diese Mängel zu beheben.

Das ändert sich langsam. Es gibt kommerzielle und freie Software-/Open-Source-Implementierungen, die diesen grundlegenden Fallstrick endlich vermeiden:

Natürlich ist der Punkt nicht dass es ein "optimales" physisches Speicherdesign geben muss, aber dass jedes physische Speicherdesign durch eine nette deklarative Sprache abstrahiert werden kann basierend auf relationaler Algebra/Kalkülen (und SQL ist ein schlechtes Beispiel) oder direkter auf einer logischen Programmiersprache (wie zum Beispiel Prolog - siehe meine Antwort auf "Prolog zu SQL-Konverter "Frage). Ein gutes DBMS sollte das physische Speicherdesign on-the-fly basierend auf Datenzugriffsstatistiken (und/oder Benutzerhinweisen) ändern.

Schließlich in Eggermonts Kommentar die Aussage " Das relationale Modell wird zwischen Cloud und Prevayler gequetscht. " ist ein weiterer Unsinn, aber ich kann hier nicht widerlegen, dieser Kommentar ist schon zu lang.