Po pierwsze, interfejs użytkownika: jako użytkownik nienawidzę wyszukiwanie produktu w katalogu zorganizowanym ściśle hierarchicznie sposób. Nigdy nie pamiętam, w jakiej pod-pod-pod-pod-kategorii znajduje się „egzotyczny” produkt, a to zmusza mnie do marnowania czasu na odkrywanie „obiecujących” kategorii tylko po to, by odkryć, że jest on sklasyfikowany w kategorii (przynajmniej dla mnie ) dziwny sposób.
Co Kevin Peno sugeruje to dobra rada i jest znana jako przeglądanie aspektowe . Jako Marcia Bates napisał w Po bombie kropkowej :Tym razem właściwe pobieranie informacji z sieci , " .. klasyfikacja aspektowa odnosi się do hierarchicznej klasyfikacji, tak jak relacyjne bazy danych do hierarchicznych baz danych... ".
Zasadniczo wyszukiwanie aspektowe pozwala użytkownikom przeszukiwać Twój katalog, zaczynając od preferowanego przez nich „aspektu”, i filtrować informacje, wybierając inne aspekty wyszukiwania. Zwróć uwagę, że w przeciwieństwie do tego, jak zwykle postrzega się systemy tagów, nic nie stoi na przeszkodzie, abyś uporządkował niektóre z tych aspektów hierarchicznie.
Aby szybko zrozumieć, o co chodzi w wyszukiwaniu aspektowym, istnieje kilka demonstracji do zbadania w Projekcie interfejsu wyszukiwania Flamenco — interfejsy wyszukiwania, które działają .
Po drugie, logika aplikacji: co Manitra
proponuje to też dobra rada (tak jak rozumiem), czyli oddzielenie nodes i links drzewa/wykresu w różnych relacjach. To, co nazywa „tablicą przodków” (co jest znacznie lepszą, intuicyjną nazwą), jest znane jako przechodnie zamknięcie skierowanego grafu acyklicznego (DAG)
(relacja osiągalności). Poza wydajnością znacznie upraszcza zapytania, jak powiedział Manitra.
Ale Proponuję widok dla takiej „tablicy przodków” (przechodniego zamykania), aby aktualizacje były w czasie rzeczywistym i przyrostowe, a nie okresowe przez zadanie wsadowe. W dokumentach, o których wspomniałem w mojej odpowiedzi na język zapytań dla zestawów wykresów:pytanie o modelowanie danych . W szczególności spójrz na Utrzymanie przejściowego zamknięcia wykresów w SQL (.ps - postscriptum).
Relacja Produkty-Kategorie
Warto również podkreślić pierwszy punkt Manitry.
Mówi, że między produktami a kategoriami istnieje relacja „wiele do wielu”. Np. każdy produkt może należeć do jednej lub więcej kategorii, aw każdej kategorii może być zero lub więcej produktów.
Biorąc pod uwagę zmienne relacyjne (zmienne relacyjne) Produkty i Kategorie taka relacja może być reprezentowana np. jako zmienna relacyjna PC z przynajmniej atrybutami P# i C#, czyli numerami produktów i kategorii (identyfikatorami) w relacji klucza obcego z odpowiadającymi im Produktami i kategoriami numery.
Jest to uzupełnienie zarządzania hierarchiami kategorii. Oczywiście to tylko szkic projektu.
O przeglądaniu aspektowym w SQL
Przydatną koncepcją do wdrożenia „przeglądania aspektowego” jest podział relacyjny , a nawet porównania relacyjne (patrz dół strony, do której prowadzi łącze). Tj. dzieląc PC (Produkty-Kategorie) przez (rosnącą) listę kategorii wybranych od użytkownika (nawigacja fasetowa) otrzymujemy tylko produkty w takich kategoriach (oczywiście kategorie są domniemane nie wszystkie wzajemnie się wykluczają, w przeciwnym razie wybierając dwie kategorie, otrzymujesz zero produktów).
DBMS oparty na SQL zwykle nie ma tych operatorów (dzielenia i porównania), więc poniżej przedstawiam kilka interesujących artykułów, które je implementują/omawiają:
- O ZROZUMIAŁOŚCI PODZIAŁU RELACYJNEGO (.pdf z Indeks sesji FIE 2003 );
- Prostsze (i lepsze) podejście SQL do podziału relacyjnego (.pdf z Journal of Information Systems Education - Spis treści, tom 13, numer 2 (2002) );
- Przetwarzanie częstych zapytań odnajdywania zestawu przedmiotów przez dzielenie i operatory łączenia zawierania zestawu ;
- Prawa dotyczące przepisywania zapytań zawierających operatorów dywizji ;
- Algorytmy i aplikacje do uniwersalnej kwantyfikacji w relacyjnych bazach danych;
- Optymalizacja zapytań z uniwersalną kwantyfikacją w obiektach i Bazy danych obiektowo-relacyjnych ;
- (Wymagany dostęp do ACM) O złożoności dzielenia i łączenia zestawów w relacyjnych algebra ;
- (Wymagany dostęp do ACM) Szybkie algorytmy do uniwersalnej kwantyfikacji w dużych bazach danych;
i tak dalej...
Nie będę tu wchodzić w szczegóły, ale interakcja między hierarchiami kategorii i przeglądaniem aspektów wymaga szczególnej uwagi.
Dygresja na temat „płaskości”
Krótko przyjrzałem się artykułowi, do którego link zawiera Pras , Zarządzanie danymi hierarchicznymi w MySQL , ale przestałem czytać po tych kilku linijkach we wstępie:
Aby zrozumieć, dlaczego ten nacisk na płaskość relacji jest po prostu nonsensem , wyobraź sobie sześcian w trójwymiarowym kartezjańskim układzie współrzędnych :będzie identyfikowany przez 8 współrzędnych (trójek), powiedzmy P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [tu nie zajmujemy się ograniczenia na te współrzędne, tak aby w rzeczywistości przedstawiały sześcian].
Teraz umieścimy ten zestaw współrzędnych (punktów) w zmiennej relacji i nazwiemy tę zmienną Points . Będziemy reprezentować wartość relacji Points jak w tabeli poniżej:
Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Czy ten sześcian jest „spłaszczany” przez sam akt przedstawiania go w sposób tabelaryczny? Czy relacja (wartość) to to samo, co jej reprezentacja tabelaryczna?
Zmienna relacyjna przyjmuje jako wartości zbiory punktów w n-wymiarowej przestrzeni dyskretnej, gdzie n jest liczbą atrybutów relacji ("kolumn"). Co to znaczy, że n-wymiarowa przestrzeń dyskretna jest „płaska”? Po prostu nonsens, jak napisałem powyżej.
Nie zrozum mnie źle, to z pewnością prawda, że SQL jest źle zaprojektowanym językiem i że DBMS-y oparte na SQL są pełne dziwactw i niedociągnięć (NULL, redundancja, ...), zwłaszcza tych złych, DBMS-as- typ śmietnika (bez ograniczeń referencyjnych, bez ograniczeń integralności, ...). Ale to nie ma nic wspólnego z wyobrażonymi ograniczeniami relacyjnego modelu danych, wręcz przeciwnie:bardziej się od nich odwracają, a wynik jest gorszy.
W szczególności relacyjny model danych, gdy już go zrozumiesz, nie stanowi problemu w reprezentowaniu jakiejkolwiek struktury, nawet hierarchii i wykresów, co szczegółowo opisałem w odniesieniach do opublikowanych artykułów wspomnianych powyżej. Nawet SQL może, jeśli pominiesz jego braki, przegapić coś lepszego.
O „Modelu zbioru zagnieżdżonego”
Przejrzałem resztę ten artykuł i nie jestem pod wrażeniem takiego logicznego projektu:sugeruje pomieszanie dwóch różnych bytów, węzłów i linki , w jedną relację i prawdopodobnie spowoduje to niezręczność. Ale nie jestem skłonny do dokładniejszej analizy tego projektu, przepraszam.
EDYTUJ: Stephan Eggermont sprzeciwił się w komentarzach poniżej, że „Problemem jest model z płaską listą. Jest to abstrakcja implementacji, która utrudnia osiągnięcie wydajności. ... ".
Teraz chodzi mi o to, że:
- ten „model płaskiej listy” to fantazja :tylko dlatego, że układa się (reprezentuje) relacje jako tabele ("płaskie listy") nie oznacza, że relacje są "płaskimi listami" ("obiekt" i jego reprezentacje to nie to samo);
- Reprezentacja logiczna (relacja) i fizyczne szczegóły dotyczące przechowywania (dekompozycja pozioma lub pionowa, kompresja, indeksy (hashe, b+drzewo, r-drzewo, ...), klastrowanie, partycjonowanie itp.) są różne; jeden z punktów relacyjnego modelu danych (RDM ) jest oddzielenie modelu logicznego od „fizycznego” (z korzyścią zarówno dla użytkowników, jak i implementatorów DBMS);
- wydajność jest bezpośrednią konsekwencją szczegółów fizycznej pamięci masowej (implementacji), a nie reprezentacji logicznej (komentarz Eggermonta jest klasycznym przykładem logiczno-fizycznego zamieszania ).
Model RDM w żaden sposób nie ogranicza implementacji; można dowolnie implementować krotki i relacje według własnego uznania. Relacje niekoniecznie pliki i krotki niekoniecznie rekordy pliku. Taka korespondencja to głupia implementacja bezpośredniego obrazu .
Niestety implementacje DBMS oparte na SQL są , zbyt często głupie implementacje obrazu bezpośredniego i mają niską wydajność w różnych scenariuszach – OLAP /ETL istnieją produkty, które pokrywają te niedociągnięcia.
To się powoli zmienia. Istnieją komercyjne i bezpłatne implementacje oprogramowania/open source, które w końcu unikają tej podstawowej pułapki:
- Vertica , który jest komercyjnym następcą...
- C-Store:DBMS zorientowany na kolumny ;
- MonetDB ;
- LucidDB ;
- Kdb w pewnym sensie;
- tak dalej...
Oczywiście chodzi o nie że musi istnieć „optymalny” projekt fizycznej pamięci masowej, ale każdy projekt fizycznej pamięci masowej można wyabstrahować za pomocą ładnego języka deklaratywnego oparte na relacyjnej algebrze/rachunkach (a SQL jest zły przykład) lub bardziej bezpośrednio w języku programowania logicznego (na przykład Prolog - zobacz moją odpowiedź na „konwerter prolog na SQL " pytanie). Dobry DBMS powinien zmieniać projekt fizycznej pamięci masowej w locie, w oparciu o statystyki dostępu do danych (i/lub wskazówki dla użytkowników).
Wreszcie, w komentarzu Eggermonta, stwierdzenie „Model relacyjny jest wciskany między chmurę a Prevayler. " to kolejna bzdura, ale nie mogę się tutaj sprzeciwić, ten komentarz jest już za długi.
