powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Иерархия
39 сообщений из 39, показаны все 2 страниц
Иерархия
    #36113564
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
есть табличка, типа есть группы в них группы или товары (как файлы-папки):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
CREATE TABLE GOOD ( --товары
      ID Integer NOT NULL, --первичный ключ
      LEFTBOUND Integer NOT NULL,
      RIGHTBOUND Integer NOT NULL,
      PARENT Integer,--сылка на группу владельца, для первого уровня NULL
      NAME Varchar( 50 ) NOT NULL, --наименование группы или товара
      ISGROUP Integer NOT NULL --признак группы: 0,1
);
правило: если товар А лежит в группе Б а та в группе С то:
Код: plaintext
C.LEFTBOUND<B.LEFTBOUND<A.LEFTBOUND=A.RIGHTBOUND<=B.RIGHTBOUND<=C.RIGHTBOUND
то есть диапозон LEFTBOUND ... RIGHTBOUND групп охватывает вложенные записи (групп и товаров)
для товаров (не групп) верно: LEFTBOUND=RIGHTBOUND

требуется написать запрос, упорядочивающий записи по иерархии, а среди записей одного уровня должны вначале идти группы, например:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
Группа 1
 Группа 1.1
  Товар 1.1.1
  Товар 1.1.2
 Товар 1.2
 Товар 1.3
Группа 2
 Группа 2.1
 Группа 2.2

смог построить запрос по-иерархии, но не добился чтобы группы в одном уровне были сверху:

Код: plaintext
1.
2.
3.
4.
select g.ID, g.Name, g.ISGROUP, count(g2.ID) as glevel
from GOOD g
left join GOOD g2 on (g.LEFTBOUND between g2.LEFTBOUND and g2.RIGHTBOUND)
group by g.ID, g.Name, g.ISGROUP, g.LEFTBOUND
order by g.LEFTBOUND

поле glevel отвечает за уровень вложенности записи

С уважением, Naf
...
Рейтинг: 0 / 0
Иерархия
    #36113594
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> требуется написать запрос

Исправьте структуру. Не читайте Celco, его примеры носят исключительно теоретический характер и на практике применяться не должны.
...
Рейтинг: 0 / 0
Иерархия
    #36113619
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> требуется написать запрос

Исправьте структуру. Не читайте Celco, его примеры носят исключительно теоретический характер и на практике применяться не должны.
это эксперимет, при малом и неоперативном изменении данных удобно (структура в основном на чтение)
выход видится один - при вставке новых групп анализировать и сдвигать LEVELBOUND вниз у элементов-не-групп
...
Рейтинг: 0 / 0
Иерархия
    #36113647
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> это эксперимет

Как получить иерархию наиболее извращенным способом? Вы понимаете, что невозможно придумать условия, которым такая реализация будет удовлетворять?

> при малом и неоперативном изменении данных удобно (структура в основном на чтение)

Удобно - это когда все иерархии в базе данных имеют общую каноническую модель и когда view получаются простыми и безгеморройными.
...
Рейтинг: 0 / 0
Иерархия
    #36113659
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> это эксперимет

Как получить иерархию наиболее извращенным способом? Вы понимаете, что невозможно придумать условия, которым такая реализация будет удовлетворять?

> при малом и неоперативном изменении данных удобно (структура в основном на чтение)

Удобно - это когда все иерархии в базе данных имеют общую каноническую модель и когда view получаются простыми и безгеморройными. Прошу Вас предложить свой вариант иерархии
...
Рейтинг: 0 / 0
Иерархия
    #36113667
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сформулируйте задачу.
...
Рейтинг: 0 / 0
Иерархия
    #36113707
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Сформулируйте задачу.
Есть справочник товаров, он должен быть иерархический. У одного элемента может быть только один владелец-группа. Вложенность не ограниченная.
Необходимо простым способом (одним запросом желательно) выводить его в иерархическом виде (это текущий топик).
Также соединять другие таблицы с ней, выводя данные по записям справочника и агрегирующие по группам. Например (упрощенно) есть также таблица
Код: plaintext
1.
2.
3.
4.
CREATE TABLE SALE (--продажи
       ID Integer NOT NULL, 
       GOOD Integer NOT NULL, --ссылка на исходный справочник
       SUMMA Numeric( 15 , 3 ) NOT NULL --сумма продажи
);
необходимо вывести таблицу в виде:
Код: plaintext
1.
2.
3.
4.
Молочные продукты 150
  Молоко          100
    Молоко 3%      70
    Молоко 6%      30
  Кефир 3%         50
вместо отступов можно выводить уровень записи(число вложений в группы)
...
Рейтинг: 0 / 0
Иерархия
    #36113729
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Есть справочник товаров

Характер справочника? Правила классификации? Предмет классификации? Область применения?
...
Рейтинг: 0 / 0
Иерархия
    #36113745
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Есть справочник товаров

Характер справочника? Правила классификации? Предмет классификации? Область применения?Правила и остальное на усмотрение пользователей оставляются. Для примера, посмотрите 1С, вот аналог справочника Номенклатура там.
...
Рейтинг: 0 / 0
Иерархия
    #36113867
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
н-да, не все так просто

внутри одной группы нужно сортировать более хитро:
сначала группы потом остальные записи, но и те и те по алфавиту

С уважением, Naf
...
Рейтинг: 0 / 0
Иерархия
    #36113877
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Правила и остальное на усмотрение пользователей

Тогда задача не имеет простого решения. Невозможно классифицировать все, что угодно, каким угодно образом.
А если не париться, то три подзадачи: собственно классификатор (включая зависимости и пр.), предмет классификации (в данном случае товары) и собственно связи между классификатором и предметами классификации.

> посмотрите 1С

Не напрягайте модератора. Одинце - то же самое, что и писанина Celco: для практического применения это непригодно.
...
Рейтинг: 0 / 0
Иерархия
    #36113910
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Правила и остальное на усмотрение пользователей

Тогда задача не имеет простого решения. Невозможно классифицировать все, что угодно, каким угодно образом.
А если не париться, то три подзадачи: собственно классификатор (включая зависимости и пр.), предмет классификации (в данном случае товары) и собственно связи между классификатором и предметами классификации.

> посмотрите 1С

Не напрягайте модератора. Одинце - то же самое, что и писанина Celco: для практического применения это непригодно.
Не надо все, надо - товары. каким образом? ну допустим по номенклатурным группам, заданным на предприятие. Например: группа "Молочные продукты" включает в себя группы "Молоко", "Кефир"...
Группа "Молоко" состоит из товаров "Молоко 3%", "Молоко 6%" ...
Товары могут иметь произвольное число вложений. Например "Молоко 3%" - 3 уровня вложенности, а "Хлеб форомовой" - 2 уровня.
А насчет непрактичности 1С, жизнь показывает обратное.
...
Рейтинг: 0 / 0
Иерархия
    #36113954
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> группа "Молочные продукты" включает в себя группы "Молоко", "Кефир"...

Так и делайте, какие проблемы? Классификатор - отдельно, товары - отдельно, связи - отдельно.
...
Рейтинг: 0 / 0
Иерархия
    #36113994
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> группа "Молочные продукты" включает в себя группы "Молоко", "Кефир"...

Так и делайте, какие проблемы? Классификатор - отдельно, товары - отдельно, связи - отдельно.Я думал над этим, чтоб группы вынести в отдельную таблицу, но что это дает, если число вложений групп заранее неизвестно? тоже самое, что они в общей таблице. В смысле та же проблема упорядочивания.
...
Рейтинг: 0 / 0
Иерархия
    #36114032
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> что это дает

Корректную модель.

> число вложений групп заранее неизвестно

И? Для каждого элемента классификатора храните уровень и глубину, если всегда нужно это знать.
...
Рейтинг: 0 / 0
Иерархия
    #36114055
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> что это дает

Корректную модель.

> число вложений групп заранее неизвестно

И? Для каждого элемента классификатора храните уровень и глубину, если всегда нужно это знать."уровень и глубину" а простите что есть глубина? уровень я определял количество вложений записи в другие. Эти данные я и так вытащить могу.
Мне нужна упорядоченность:
- по иерархии, внутри нее
- по признаку группа или нет (сначала группы), среди них по алфавиту
...
Рейтинг: 0 / 0
Иерархия
    #36114062
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в общем, вы можете конкретный (достаточно простой) пример привести
желательно без рекурсивного вызова процедур
С уважением, Naf
...
Рейтинг: 0 / 0
Иерархия
    #36114126
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем задача такая: какая наиболее оптимальная структура таблицы справочника, чтобы наиболее просто получать иерархический список (упорядоченность по иерархии и доп. полю, например наименованию или признаку группы + наименованию)
Соответственно, достаточно просто получать агрегатные функции из других таблиц с учетом иерархии.
Достаточно просто - это одним запросом и без рекурсии хранимых процедур.

С уважением, Naf
...
Рейтинг: 0 / 0
Иерархия
    #36114756
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Когда в практике ты "ноль" можно по теоретизировать.
Итак, пусть есть таблица представляющая собой некое множество записей, на котором хотим задать отношение полного порядка (а попросту, упорядочить каким-то способом). Обозначим A>>B если в нашем упорядочивании запись A идет раньше B.
Введем функцию r(A,B) =1, если A>>B и =0 иначе.
Очевидно, что r(A,A)=0; r(A,B)=1-r(B,A); если r(A,B)=r(B,C)=1 тогда r(A,С)=1.
Тогда функция R(A)=Sum(r(A,B),B-пробегает все множество) принимает различные значения 0,1,...,Count(*)-1 и задает тот же порядок на целых числах.
Переводя в SQL, получаем запрос "универсального" упорядочивания:
Код: plaintext
1.
2.
3.
4.
SELECT A.Х
FROM T as A
LEFT JOIN T as B on ( 1 = 1 )
GROUP BY A.X
ORDER BY SUM(r(A,B)) DESC --запись формальная естественно
или тоже самое
Код: plaintext
1.
2.
3.
4.
SELECT A.Х
FROM T as A
LEFT JOIN T as B on (r(A,B)= 1 )
GROUP BY A.X
ORDER BY COUNT(B.Х) DESC
естественно, не стоит применять такой запрос при простом упорядочивании. Я вообще не знаю где его можно применить ))).

Вернемся к текущей задаче. Необходимо упорядочить множество по-иерархии (обозначим >>) и внутри одной ветки иерархии по другому признаку, например паре IsGroup,Name (обозначим >).
Итак, для каждой записи можно указать "родительскую", на которую ссылается Parent. Для каждой записи A можно записать родительский ряд:
A=A0<<A1<<...<<An=NULL где Ai.Parent = A(i+1).
Для пары (A,B) минимальным предком X назовем запись наибольшего уровня вложенности, одновременно встречающееся в родительских рядах A и B (возможно NULL). Если A и B не расположены в одном родительском ряду, то минимальные индивидуальные родители относительно A и B это элементы в родительских рядах An<<X и Bm<<X (предшествующие X непосредственно).
Тогда введенная ранее функция r(A,B) равна 1 тогда и только тогда, когда:
1. B!=A и A лежит в родительском ряду B.
либо
2. An>Bm (верно второе упорядочивание).
Как видно из написанного нам понадобится использование LEFTBOUND и RIGHTBOUND, но придется использовать многократное соединение таблицы самой с собой. А именно: найти минимального предка, найти индивидуальных предков и сравнить их.
Но, зачастую, практика это не теория, надеюсь на более простое решение задачи.

С уважением, Naf
...
Рейтинг: 0 / 0
Иерархия
    #36114993
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вы не имеете ни малейшего представления ни о классификации, ни о проектировании, ни о теории множеств. Я не могу тратить свое время на глупые измышления.
...
Рейтинг: 0 / 0
Иерархия
    #36115007
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Вы не имеете ни малейшего представления ни о классификации, ни о проектировании, ни о теории множеств. Я не могу тратить свое время на глупые измышления.От Вас я тоже никакой конкретики не увидел. Можете не тратить свое время на меня, а я свое на Вас.
...
Рейтинг: 0 / 0
Иерархия
    #36115303
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вывод дерева с сортировкой внутри каждого уровня:
Код: plaintext
1.
2.
3.
4.
5.
SELECT last_name, employee_id, manager_id, LEVEL
FROM employees
START WITH employee_id =  100 
CONNECT BY PRIOR employee_id = manager_id
ORDER SIBLINGS BY last_name; 
...
Рейтинг: 0 / 0
Иерархия
    #36115551
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
н-да, без специфики серверов, то есть максимально переносимо между СУБД вышло вот так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
SELECT 
T.ID1 ID ,T.NAME1 NAME, COUNT(DISTINCT GLEV.ID) LEV
FROM
(SELECT G1.ID ID1, G2.ID ID2, MAX(MP.LEFTBOUND) MPL, MIN(MP.RIGHTBOUND) MPR, G1.LEFTBOUND GL1, G2.LEFTBOUND GL2, G1.NAME NAME1 
FROM GOOD G1
LEFT JOIN GOOD G2 ON NOT(G1.ID=G2.ID)
LEFT JOIN GOOD MP ON ((G1.LEFTBOUND BETWEEN MP.LEFTBOUND AND MP.RIGHTBOUND) AND (G2.LEFTBOUND BETWEEN MP.LEFTBOUND AND MP.RIGHTBOUND))
GROUP BY G1.ID, G2.ID, G1.LEFTBOUND, G2.LEFTBOUND, G1.NAME) T 
LEFT JOIN GOOD MP0 ON (MP0.LEFTBOUND = T.MPL)
LEFT JOIN GOOD GI1 ON ((GI1.PARENT = MP0.ID) OR ((MP0.ID IS NULL) AND (GI1.PARENT IS NULL))) AND (T.GL1 BETWEEN GI1.LEFTBOUND AND GI1.RIGHTBOUND)
LEFT JOIN GOOD GI2 ON ((GI2.PARENT = MP0.ID) OR ((MP0.ID IS NULL) AND (GI2.PARENT IS NULL))) AND (T.GL2 BETWEEN GI2.LEFTBOUND AND GI2.RIGHTBOUND)
LEFT JOIN GOOD GLEV ON (T.GL1 BETWEEN GLEV.LEFTBOUND AND GLEV.RIGHTBOUND) 
GROUP BY T.ID1, T.NAME1
ORDER BY
      SUM(
      CASE
        WHEN T.ID1=MP0.ID THEN  1 
        WHEN T.ID2=MP0.ID THEN  0 
        WHEN (GI1.ISGROUP>GI2.ISGROUP) THEN  1 
        WHEN (GI1.ISGROUP<GI2.ISGROUP) THEN  0         
        WHEN (GI1.NAME<GI2.NAME) THEN  1         
        ELSE  0 
      END) DESC
...
Рейтинг: 0 / 0
Иерархия
    #36115554
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
интересно насколько это хуже рекурсии?
С уважением, Naf
...
Рейтинг: 0 / 0
Иерархия
    #36115711
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
поправить упорядочивание на:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
ORDER BY
     COUNT( DISTINCT
     CASE
       WHEN T.ID1=MP0.ID THEN ID2
       WHEN T.ID2=MP0.ID THEN NULL
       WHEN (GI1.ISGROUP>GI2.ISGROUP) THEN ID2
       WHEN (GI1.ISGROUP<GI2.ISGROUP) THEN NULL        
       WHEN (GI1.NAME<GI2.NAME) THEN ID2        
       ELSE NULL
     END)
...
Рейтинг: 0 / 0
Иерархия
    #36116998
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
улучшил:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
SELECT 
G1.ID ID ,G1.NAME NAME, 
      SUM(
      CASE WHEN G1.LEFTBOUND BETWEEN G2.LEFTBOUND AND G2.RIGHTBOUND THEN  1 
           ELSE  0 
      END) LEV
FROM GOOD G1
LEFT JOIN GOOD G2 ON NOT(G1.ID=G2.ID)
LEFT JOIN GOOD GI1 ON (G1.LEFTBOUND BETWEEN GI1.LEFTBOUND AND GI1.RIGHTBOUND)
LEFT JOIN GOOD GI2 ON (G2.LEFTBOUND BETWEEN GI2.LEFTBOUND AND GI2.RIGHTBOUND)
WHERE
     ((GI1.PARENT=GI2.PARENT) OR ((GI1.PARENT IS NULL)AND(GI2.PARENT IS NULL))) AND
     (NOT(GI1.ID=GI2.ID) OR (G1.ID=GI1.ID) OR (G2.ID=GI2.ID))   
GROUP BY G1.ID, G1.NAME
ORDER BY
     SUM( 
     CASE
       WHEN G2.LEFTBOUND BETWEEN G1.LEFTBOUND AND G1.RIGHTBOUND THEN  1 
       WHEN G1.LEFTBOUND BETWEEN G2.LEFTBOUND AND G2.RIGHTBOUND THEN  0 
       WHEN (GI1.ISGROUP>GI2.ISGROUP) THEN  1 
       WHEN (GI1.ISGROUP<GI2.ISGROUP) THEN  0         
       WHEN (GI1.NAME<GI2.NAME) THEN  1         
       ELSE  0 
     END) DESC
С уважением, Naf
...
Рейтинг: 0 / 0
Иерархия
    #36117474
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наконец, допустим есть таблица продаж (очень упрощенно)
Код: plaintext
1.
2.
3.
4.
5.
6.
CREATE TABLE SALE (
       ID Integer NOT NULL,
       GOOD Integer NOT NULL,
       ACOUNT Numeric( 15 , 3 ) NOT NULL,
       CONSTRAINT PK_SALE PRIMARY KEY (ID)
);
ALTER TABLE SALE ADD CONSTRAINT FK_SALE_1 FOREIGN KEY (GOOD) REFERENCES GOOD(ID);
И нам необходимо вывести продаваемые продукты по-иерархии с требуемой сортировкой:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
SELECT T.ID ID ,T.NAME NAME, T.LEV LEV, SUM(S.ACOUNT) ACOUNT
FROM SALE S
INNER JOIN GOOD G ON (S.GOOD=G.ID)
INNER JOIN
(SELECT 
G1.ID ID ,G1.NAME NAME, G1.LEFTBOUND LEFTBOUND, G1.RIGHTBOUND RIGHTBOUND, 
      SUM(
      CASE WHEN G1.LEFTBOUND BETWEEN G2.LEFTBOUND AND G2.RIGHTBOUND THEN  1 
           ELSE  0 
      END) LEV,
     SUM( 
     CASE
       WHEN G2.LEFTBOUND BETWEEN G1.LEFTBOUND AND G1.RIGHTBOUND THEN  1 
       WHEN G1.LEFTBOUND BETWEEN G2.LEFTBOUND AND G2.RIGHTBOUND THEN  0 
       WHEN (GI1.ISGROUP>GI2.ISGROUP) THEN  1 
       WHEN (GI1.ISGROUP<GI2.ISGROUP) THEN  0         
       WHEN (GI1.NAME<GI2.NAME) THEN  1         
       ELSE  0 
     END) ORD
FROM GOOD G1
LEFT JOIN GOOD G2 ON NOT(G1.ID=G2.ID)
LEFT JOIN GOOD GI1 ON (G1.LEFTBOUND BETWEEN GI1.LEFTBOUND AND GI1.RIGHTBOUND)
LEFT JOIN GOOD GI2 ON (G2.LEFTBOUND BETWEEN GI2.LEFTBOUND AND GI2.RIGHTBOUND)
WHERE
     ((GI1.PARENT=GI2.PARENT) OR ((GI1.PARENT IS NULL)AND(GI2.PARENT IS NULL))) AND
     (NOT(GI1.ID=GI2.ID) OR (G1.ID=GI1.ID) OR (G2.ID=GI2.ID))   
GROUP BY G1.ID, G1.NAME, G1.LEFTBOUND, G1.RIGHTBOUND) T 
      ON ((G.ID=T.ID) OR (G.LEFTBOUND BETWEEN T.LEFTBOUND AND T.RIGHTBOUND))
GROUP BY T.ID,T.NAME,T.LEV, T.ORD      
ORDER BY T.ORD DESC
С уважением, Naf
...
Рейтинг: 0 / 0
Иерархия
    #36117955
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nafесть табличка, типа есть группы в них группы или товары (как файлы-папки)Не самая подходящая аналогия, IMHO. Не стоит смешивать группы и товары в одной таблице. Этим, как минимум, усложняется проверка корректности данных. Например, группа может оказаться потомком товара, да и иерархичность товара вызывает сомнения.

Хранение иерархии "методом Селко" может показаться привлекательным чисто теоретически, но, как показала практика, он больше вызывает проблем, чем их решает. Разумеется, никто не может помешать проверить это утверждение самому. Какой метод выбрать взамен него, трудно сказать однозначно. Для некоторых задач вполне достаточно стандартной пары (ID, ParentID) и рекурсивных запросов.

Иерархия групп товаров - вещь, как минимум, очень неудобная, хотя бы по причине "жёсткости". В данном случае, IMHO, стоило бы применить "теговый" подход, когда к товару можно "прицепить" какие угодно теги, каждый из которых представляет собой ссылку на некий классификатор, в том числе и иерархический, если возникнет острая необходимость. Т.е., классический вариант связи M:N, реализованный через дополнительную таблицу, где с одной стороны товары, а с другой - теги(ссылки на классификаторы). Такой подход позволит строить "визуальные" иерархии, наиболее уместные в конкретной ситуации или для конкретного пользователя простым выбором последовательности тегов. Например, сначала по производителям, а потом по видам продукции, а можно наоборот, сначала по видам продукции, а потом по производителям.

P.S. Хотелось бы отметить, что на практике, IMHO, часто тяготеют к иерархическим структурам, где их наличие совершенно неоправданно. "Истинных" иерархий, подобно генеалогическому дереву, на практике не так уж и много. В таких случаях обычно подразумеваются, что все элементы этой иерархии однотипны.
...
Рейтинг: 0 / 0
Иерархия
    #36168878
Фотография Roman S. Golubin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChAХранение иерархии "методом Селко" может показаться привлекательным чисто теоретически, но, как показала практика, он больше вызывает проблем, чем их решает.
Хмм... голословное утверждение. Знаю как минимум два случая из личной практики, когда применение метода Селко избавило от необходимости приобретения дорогущего железа. При этом сложность добавления/удаления/изменения данных для процедур, которые с этим деревом работали, ни как не изменилась. Вместо корявых и медленных циклов / курсоров / CTE для выборки данных из деревянной структуры, были написаны однопроходные запросы и построены индексы. При этом, скорость работы увеличилась на несколько порядков, а нагрузка на железо упала в несколько раз.
...
Рейтинг: 0 / 0
Иерархия
    #36168923
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman S. Golubinголословное утверждение.Роман, могу ответить в том же духе, твои примеры тоже являются голословным утверждением. Дабы избегать ненужного эпатажа и сосредоточиться на сути, предлагаю в дальнейшем исключить подобные формулировки. Мои утверждения основаны на моей практике, твои на твоей, давай исходить из этого.
Roman S. GolubinЗнаю как минимум два случая из личной практики, когда применение метода Селко избавило от необходимости приобретения дорогущего железа. При этом сложность добавления/удаления/изменения данных для процедур, которые с этим деревом работали, ни как не изменилась.Разумеется, если использовать метод вложенных множеств(Селко) в качестве альтернативы дилетантским решениям, то не исключаю, что он может выиграть по некоторым пунктам. Но от его родового проклятия, пересчёта и модификации LR-значений, в среднем затрагивающих до половины узлов дерева, увы, не избавиться.
Если использовать большую разреженность значений, чтобы снизить объем модификаций, то мы теряем некоторые преимущества, которые даёт непрерывность LR-последовательности, при этом дополнительная проверка на предмет нахождения внутри псевдофиксированных границ остаётся.
Даже для простейшего поиска всех потомков узла необходимо использовать слияние, для получения по идентификатору узла его LR-значений, чтобы выбрать потомков, чьи LR-значения находятся внутри LR-границ предка. Причем сами LR-значения мы не можем использовать в качестве ключа в связи с их потенциальной изменчивостью.
Поиск всех предков листа приводит к сканированию всех узлов дерева, что с учётом потенциальной перестройки дерева при модификации может породить немало проблем. То же самое произойдёт при попытке вычислить уровень листа.
Слишком часто используется between, что мешает использованию merge- и hash-алгоритмов при различных выборках. Да и с индексом есть проблемы, так как у нас для каждого узла есть 2 совершенно независимых друг от друга значения. В результате, польза от индекса (L,R) невелика, а использование 2 отдельных индексов по L и R сервером запросто игнорируется с точки зрения IO. Дешевле сделать seek+scan по какому-либо одному из них.
Roman S. GolubinВместо корявых и медленных циклов / курсоров / CTE для выборки данных из деревянной структуры, были написаны однопроходные запросы и построены индексы. При этом, скорость работы увеличилась на несколько порядков, а нагрузка на железо упала в несколько раз.Я тоже видел много ужасных реализаций, но это говорит лишь об уровне их авторов. Тем более, что ты упомянул создание индексов, исключение курсоров. Так зачем же противопоставлять заведомо плохую реализацию работы с деревом и метод вложенных множеств, который при реализации тем же программистом мог бы точно так же, если не хуже, похоронить сервер ?
Цикла в случае стандартных (ID, ParentID) может и не избежать, но без курсоров можно запросто обойтись, этот способ был предложен в BOL еще к MS SQL версии 4.21. Почти уверен, что нормальная реализация такого подхода не сильно бы уступала методу вложенных множеств.
В случае неглубоких деревьев(2-3 уровня, что нередко бывает на практике) не думаю, что CTE принципиально проигрывает методу вложенных множеств при "правильных" индексах. Впрочем, это моё голословное, умозрительное, утверждение, сам экспериментов не ставил. Если есть обратная статистика, а ещё лучше, воспроизводимый пример, то был бы рад ознакомиться.

IMO, метод вложенных множеств может использоватся в случае не очень больших и редкоизменяющихся деревьев. Лично я исключил его из своей практики, предпочитаю развёртывание иерархии в дополнительных полях и/или таблицах.
...
Рейтинг: 0 / 0
Иерархия
    #36168936
Фотография Roman S. Golubin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChA,

По поводу использования LR в качестве ключа - это жестко :) Я использовал все ту же старую модель ID/ParentID в связке с LR - индекс позволяет выбрать пару с помощью Seek. И да, в обоих случаях имелось очень большое, основательно развлетвленное и не очень активно (примерно 2-3 раза в час) изменяющееся дерево, управление структурой которого было отдано пользователям. При этом затык производительности был именно на получении потомков / путей к корню - множество поисковых запросов через web.
Перед началом перехода на метод Селко рядом стоял костыль в виде отдельного сервера Oracle, на котором курсоры (по непонятной мне причине - ни разу не пользовался ораклом ) работали на порядок быстрее, чем на MS SQL. На этом оракле и крутилось дерево.
На счет ужасности реализации - не знаю, как все это было реализовано до того, как перестало хватать железа и был установлен оракловый сервер - история об этом умалчивает :)
...
Рейтинг: 0 / 0
Иерархия
    #36173126
Борис Бритва
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а вы еще добавте одно поле "уровень иерархии", оно может и лишнее но поможет Вам и сейчас и в будующем.

CREATE TABLE GOOD ( --товары
ID Integer NOT NULL, --первичный ключ
LEFTBOUND Integer NOT NULL,
RIGHTBOUND Integer NOT NULL,
PARENT Integer,--сылка на группу владельца, для первого уровня NULL
NAME Varchar(50) NOT NULL, --наименование группы или товара
ISGROUP Integer NOT NULL --признак группы: 0,1

LEVEL Integer NOT NULL
);
...
Рейтинг: 0 / 0
Иерархия
    #36173174
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Борис Бритваа вы еще добавте одно поле "уровень иерархии", оно может и лишнее но поможет Вам и сейчас и в будующем.

CREATE TABLE GOOD ( --товары
ID Integer NOT NULL, --первичный ключ
LEFTBOUND Integer NOT NULL,
RIGHTBOUND Integer NOT NULL,
PARENT Integer,--сылка на группу владельца, для первого уровня NULL
NAME Varchar(50) NOT NULL, --наименование группы или товара
ISGROUP Integer NOT NULL --признак группы: 0,1

LEVEL Integer NOT NULL
);возможно, но в тоже время оно легко вычисляется
...
Рейтинг: 0 / 0
Иерархия
    #36174278
Борис Бритва
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Naf,

c таким же успехом Вы можетесказать, что поля PARENT и ISGROUP - излишества) и вообще табличку надо нормализовать)
Вам не кажется что для таких запрросов используется подход, который позволяет оптимизировать время выполнения запроса, и позволяет строить интутивно понятные с первого взгляда простые запосы.
Представляете себе запрос такого вида как Вы предложили хотя бы для 5 измерений? =)
...
Рейтинг: 0 / 0
Иерархия
    #36174384
Борис Бритва
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Подумайте, может Вам в условии JOIN юзать BETWEEN и тогда будет удобней?

SELECT
GOOD.NAME,
SUM( SALE.AMOUNT ) AS AMOUNT
FROM
GOOD
LEFT OUTER JOIN
SALE
ON ( SALE.GOOD BETWEEN GOOD.LEFTBOUND AND GOOD.RIGHTBOUND)
GROUP BY GOOD.NAME
ORDER BY GOOD.LEFTBOUND
...
Рейтинг: 0 / 0
Иерархия
    #36174962
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Борис БритваNaf,

c таким же успехом Вы можетесказать, что поля PARENT и ISGROUP - излишества) и вообще табличку надо нормализовать)
Вам не кажется что для таких запрросов используется подход, который позволяет оптимизировать время выполнения запроса, и позволяет строить интутивно понятные с первого взгляда простые запосы.
Представляете себе запрос такого вида как Вы предложили хотя бы для 5 измерений? =)нормализовать можно, но денормализация специально внесена для ускорения выборок
...
Рейтинг: 0 / 0
Иерархия
    #36174966
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Борис БритваПодумайте, может Вам в условии JOIN юзать BETWEEN и тогда будет удобней?

SELECT
GOOD.NAME,
SUM( SALE.AMOUNT ) AS AMOUNT
FROM
GOOD
LEFT OUTER JOIN
SALE
ON ( SALE.GOOD BETWEEN GOOD.LEFTBOUND AND GOOD.RIGHTBOUND)
GROUP BY GOOD.NAME
ORDER BY GOOD.LEFTBOUNDмне не нужны все товары, а только которые есть в SALE. Да и сортировки требуемой нет
...
Рейтинг: 0 / 0
Иерархия
    #36175086
Борис Бритва
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Naf,

у меня с сортировкой все в порядке. Может у Вас в данных неправильно указаны левые и правые границы?
...
Рейтинг: 0 / 0
Иерархия
    #36175200
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Борис Бритва,

я про ту сортировку, ради которой весь топик заводился
...
Рейтинг: 0 / 0
39 сообщений из 39, показаны все 2 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Иерархия
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]