Необходими са съвети относно структурата на базата данни

Първо, потребителският интерфейс: като потребител мразя за търсене на продукт в каталог, организиран в строго йерархичен начин. Никога не си спомням в коя под-под-под-под...-категория е "екзотичен" продукт и това ме принуждава да губя време в проучване на "обещаващи" категории, само за да открия, че е категоризиран в (за мен поне ) странен начин.

Какво Кевин Пено предлага е добър съвет и е известен като фасетно сърфиране . Като Марсия Бейтс написа в След Dot-Bomb :Получаване на правилното извличане на информация този път , " .. фасетната класификация е към йерархична класификация, както релационните бази данни са към йерархични бази данни. .. ".

По същество фасетното търсене позволява на потребителите да търсят в каталога ви, започвайки от какъвто „фасет“ предпочитат и им позволява да филтрират информацията, като избират други аспекти по време на търсенето. Обърнете внимание, че противно на начина, по който обикновено се замислят системите за етикети, нищо не ви пречи да организирате някои от тези аспекти йерархично.

За да разберете бързо какво представлява фасетното търсене, има някои демонстрации за да разгледате в Проектът за интерфейса за търсене на фламенко – интерфейси за търсене, които текат .

Второ, логиката на приложението: какво Manitra proposes също е добър съвет (както го разбирам), т.е. разделяне на nodes и links на дърво/графа в различни отношения. Това, което той нарича „таблица на предците“ (което обаче е много по-добро интуитивно име) е известно като преходно затваряне на насочен ацикличен граф (DAG) (отношение на достижимост). Освен производителността, това опростява заявките значително, както каза Манитра.

Но Предлагам изглед за такава "таблица на предшествениците" (преходно затваряне), така че актуализациите да са в реално време и постепенно, а не периодично чрез пакетно задание. Има SQL код (но мисля, че трябва да бъде адаптиран малко към конкретни DBMS) в документи, които споменах в отговора си на език на заявка за набори от графики:въпрос за моделиране на данни . По-специално, вижте Поддържане на транзитивно затваряне на графики в SQL (.ps - постскриптум).

Връзка Продукти-Категории

Първата точка от Манитра също заслужава да се наблегне.

Това, което той казва, е, че между продуктите и категориите има връзка много към много. Т.е.:всеки продукт може да бъде в една или повече категории и във всяка категория може да има нула или повече продукти.

Дадени релационни променливи (relvars) Продукти и категории такава връзка може да бъде представена, например, като relvar PC с най-малко атрибути P# и C#, т.е. номера на продукти и категории (идентификатори) във връзки с външен ключ със съответните продукти и категории числа.

Това е допълнение към управлението на йерархиите на категориите. Разбира се, това е само дизайнерска скица.

При фасетирано сърфиране в SQL

Полезна концепция за прилагане на „фасетирано сърфиране“ е релационно разделение , или дори релационни сравнения (вижте долната част на свързаната страница). т.е. разделяйки компютър (продукти-категории) на (нарастващ) списък с категории, избрани от потребител (навигация по аспекти), се получават само продукти в такива категории (разбира се, категориите се предполага, че не всички взаимно изключващи се, в противен случай избирането на две категории една ще получи нулеви продукти).

Базираната на SQL СУБД обикновено няма тези оператори (разделяне и сравнения), така че давам по-долу някои интересни документи, които ги прилагат/обсъждат:

и така нататък...

Тук няма да навлизам в подробности, но взаимодействието между йерархиите на категориите и разглеждането на аспекти изисква специално внимание.

Отклонение за "плоскост"

Разгледах накратко статията, свързана от Pras , Управление на йерархични данни в MySQL , но спрях да чета след тези няколко реда в увода:

Да разберем защо това настояване за плоскост на отношенията епросто глупост , представете си куб в триизмерна декартова координатна система :ще бъде идентифициран с 8 координати (тройки), да речем P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [тук не се занимаваме с ограничения върху тези координати, така че да представляват наистина куб].

Сега ще поставим този набор от координати (точки) в релационна променлива и ще наречем тази променлива Points . Ние щепредставяме стойността на връзката на Points като таблица по-долу:

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

Дали този куб се „сплесква“ само чрез представянето му в табличен начин? Връзката (стойността) е същото нещо като нейното таблично представяне?

Релационна променлива приема като стойности набори от точки в n-мерно дискретно пространство, където n е броят на релационните атрибути („колони“). Какво означава за n-мерно дискретно пространство да бъде "плоско"? Просто глупости, както писах по-горе.

Не ме разбирайте погрешно, със сигурност е вярно, че SQL е лошо проектиран език и че базираните на SQL СУБД са пълни с идиосинкразии и недостатъци (NULL, излишък, ...), особено лошите, СУБД като- тип dumb-store (без референтни ограничения, без ограничения за целостта, ...). Но това няма нищо общо с фантазираните ограничения на релационния модел на данни, напротив:повече те се отклоняват от него и по-лош е резултатът.

По-специално, моделът на релационните данни, след като го разберете, не представлява проблем при представянето на каквато и да е структура, дори йерархии и графики, както описах подробно с препратки към публикувани статии, споменати по-горе. Дори SQL може, ако прикриете недостатъците му, да пропуснете нещо по-добро.

Върху „Модела на вложен набор“

Прегледах останалата част от тази статия и не съм особено впечатлен от такъв логичен дизайн:предлага да се смесят две различни единици, възли ивръзки , в една връзка и това вероятно ще предизвика неловкост. Но не съм склонен да анализирам този дизайн по-задълбочено, съжалявам.

РЕДАКТИРАНЕ: Стефан Егермонт възрази в коментарите по-долу, че " Моделът на плоския списък е проблем. Това е абстракция на внедряването, което прави производителността трудна за постигане. ... ".

Сега, моята гледна точка е точно това:

този „модел с плосък списък“ е фантазия :само защото една подредба (представлява) релации като таблици („плоски списъци“) не означава, че релациите са „плоски списъци“ („обект“ и неговите представяния не са едно и също нещо);
логическо представяне (връзка) и подробности за физическото съхранение (хоризонтални или вертикални декомпозиции, компресия, индекси (хешове, b+дърво, r-дърво, ...), групиране, разделяне и т.н.) са различни; една от точките на релационния модел на данни (RDM ) е да отделя логическия от „физическия“ модел (с предимства както за потребителите, така и за внедрителите на СУБД);
изпълнението е пряко следствие от подробностите за физическото съхранение (внедряване) и не на логическо представяне (коментарът на Егермонт е класически пример за логико-физическо объркване ).

RDM моделът не ограничава реализациите по никакъв начин; човек е свободен да прилага кортежи и релации, както намери за добре. Отношенията сане е задължително файловете и кортежите сане е задължително записи на файл. Подобна кореспонденция е тъпа директна реализация на изображение .

За съжаление SQL-базираните имплементации на СУБД са твърде често тъпи реализации на директни изображения и страдат от лоша производителност в различни сценарии - OLAP /ETL съществуват продукти за покриване на тези недостатъци.

Това бавно се променя. Има комерсиални и безплатни реализации на софтуер/отворен код, които най-накрая избягват този основен капан:

Vertica , който е търговски наследник на..
C-Store:СУБД, ориентирана към колони ;
MonetDB ;
LucidDB ;
Kdb по някакъв начин;
и така нататък...

Разбира се, въпросът ене че трябва да съществува "оптимален" дизайн на физическо съхранение, но че какъвто и физически дизайн за съхранение може да се абстрахира от приятен декларативен език базиран на релационна алгебра/изчисления (а SQL е лош например) или по-директно на език за логично програмиране (като Prolog, например - вижте моя отговор на "пролог към SQL конвертор " въпрос). Добрата СУБД трябва да променя дизайна на физическото хранилище в движение, въз основа на статистически данни за достъпа до данни (и/или подсказки за потребителя).

И накрая, в коментара на Егермонт изявлението „ Релационният модел се притиска между облака и преобладаващия. " е още една глупост, но не мога да опровергая тук, този коментар вече е твърде дълъг.