0. ildarovich 6766 22.08.19 18:00 Сейчас в теме

Иерархия без "В ИЕРАРХИИ"

Говорится о том, как эффективно представлять иерархию в СУБД, как получать и использовать эти представления при решении задач в запросной технике. Уточняются и дополняются запросы из статьи "Уровни, глубина, прародители, циклы и аналоги запросом" [https://infostart.ru/public/160707/].

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. PerlAmutor 47 22.08.19 19:55 Сейчас в теме
Недавно решал задачу по хранению иерархии во внешнем источнике данных. Выбрал вложенные множества для этой цели. Пришлось дорабатывать процедуру конвертации Joe Celko с AL на свой формат хранения иерархических данных, у меня это был граф (многие родители могли в своем составе иметь одного и того же ребенка). После разрыва связей и дублировании подчинения, база со 100Мб и 400000 элементами, развернулась в деревья в 100Гб и 30 млн. записей. Пришлось пойти на жертвы, чтобы состав любого древа получался за линейное время. Узким местом оказалась сама ERP, куда хлынул поток ресурсных спецификаций изделий. С таким наплывом она не справилась. Но хуже всего дело обстоит у неё с версионированием ресурсных спецификаций. В структуре изделий периодически что-то меняется. Единственный выход - строить все заново каждый раз, так как уже созданные этапы производства трогать нельзя. Все это ведет к разбуханию базы мусорными данными, которые никогда больше использоваться не будут, но привязаны к документам.
MCV; jONES1979; Артано; gazpromsera; ildarovich; Rustig; +6 Ответить
3. Summer_13 22.08.19 21:48 Сейчас в теме
(1)Можно,пожалуйста, перестать писать комментарии под каждым постом,где требуется,что-то оптимизировать по вашему мнению?
4. PerlAmutor 47 23.08.19 06:22 Сейчас в теме
(3) Было бы неплохо, если 1С добавила новый вид регистра сведений - Иерархический, с одним из вариантов хранения данных, как минимум Adjacency List и Nested Sets. С добавлением к ним новых виртуальных функций позволяющих решать большинство задач связанных с поиском и модификации данных, без составления сложных запросов. А также методов преобразования иерархических данных из одного вида в другой и обратно.
Артано; Krio2; bulpi; Chai Nic; +4 Ответить
5. Chai Nic 135 23.08.19 08:11 Сейчас в теме
(4) Достаточно сделать для иерархических справочников "групповые агрегаты", то есть таблицу, которая бы хранила полную таблицу принадлежности групп и элементов, и обновлялась автоматически, эквивалентно механизму итогов и агрегатов. Тогда проверка на принадлежность будет выполняться за один индексный выбор СУБД. Разумеется, это должно быть опцией, галочкой в настройке справочника в конфигураторе.
6. SlavaKron 23.08.19 08:28 Сейчас в теме
(4)
с одним из вариантов хранения данных, как минимум Adjacency List

Так Adjacency List - это и есть текущий вариант хранения иерархии в 1С, насколько я понял.
13. PerlAmutor 47 23.08.19 19:56 Сейчас в теме
(6) В справочнике - да. Мне хочется иерархический регистр, чтобы без пометок на удаление, с возможностью перестроения деревьев в любой момент без контроля ссылочной целостности.
8. Rustig 1210 23.08.19 09:31 Сейчас в теме
(4) для таких задач создаете свои промежуточные таблицы, которые постоянно обновляются по определенным событиям. и не надо тогда будет использовать сложные запросы. универсального решения нет, под каждую задачу создаете свой механизм и логику. что-то подобное я описал здесь https://infostart.ru/public/195627/
2. Поручик 4331 22.08.19 20:22 Сейчас в теме
Статьи ildarovich'a можно сразу добавлять в избранное, не читая.
jONES1979; Krio2; gubanoff; NeviD; json; bulpi; u_n_k_n_o_w_n; Volosokrad1990; kuzyara; AllexSoft; skv_79; DarkAn; Ali1976; RocKeR_13; PLAstic; alalsl; Summer_13; acanta; BlizD; Yimaida; +20 Ответить
7. AlX0id 23.08.19 09:06 Сейчас в теме
(2)
Ага, и интеллект +1 моментально ))
user774630; +1 Ответить
9. Rustig 1210 23.08.19 09:33 Сейчас в теме
(7) не читая? уровень сложности статей 10 баллов из 10.... не все дочитают до конца, и не все поймут...
user774630; +1 Ответить
10. DarkAn 904 23.08.19 10:19 Сейчас в теме
(9) может и 10 и 11, пофиг. Главное, что читающий хочет в статье почерпнуть?

Если статьи читать, как художественную литературу - то да - скучно. А если попытаться разобраться в том, как "оно" работает, то это очень интересно и позволит увеличивает твою "копилку" инструментов.

При этом у автора, много статей опирающиеся на один метод - "Транзитивного замыкания" (есть и другие) и надо потратить свои усилия и разобраться в его работе. А далее уже продолжить изучать другие стати, где автор приводит примеры использования данного метода.

Лично мне данный метод очень пригодился, когда надо было найти всех "последних" потомков для кучи родителей. и стандартно пришлось бы писать запрос в цикле, что было бы долго, а воспользовавшись преложенным методом удалось все решить 1 запросом. Единственным неудобством данного метода я считаю - это то что запрос не "статичный", а генерируемый в зависимости от справочника, но это мелочи по сравнению с результатом.
15. gaglo 26.08.19 18:19 Сейчас в теме
(7) Муахахахахха, не моментально.... Интеллект +1 после прочтения добавленного и осознания прочитанного.
А моментально, не читая = +1 к чему-то другому.
11. bulpi 158 23.08.19 12:14 Сейчас в теме
"Максимальная длина строки, хранящейся в базе, равна 1024 символа. Следовательно, при девятизначном коде и одном разделителе возможно представить иерархию не более чем из 64 уровней."

Не понял. 1024/10=102, а не 64.
12. ildarovich 6766 23.08.19 12:51 Сейчас в теме
(11) Да, понял, что нужно было поподробнее пояснить, что я имел ввиду.

Сначала поле "Путь" будет длины 9 + 1 = 10.
В первом соединении его длина станет 20, во втором - 40, в третьем - 80, ..., шестом - 640.
Седьмое удваивающее соединение в приведенной схеме запроса сделать уже не получится, так как результат будет уже 1280 - больше допустимой длины строки.

Там еще есть детали по поводу юникода и что строка из-за этого может быть практически до 2048 длиной, но нужно проверять на разных СУБД конкретно. Также при желании эти 1024 можно плотнее упаковать, соединяя не MP6 и МР6, а МР6 и MP5, но для практики и 640 более чем достаточно.

Еще из важных мелких деталей, которые нужно не забыть добавить в статью, это символ разделителя "/" и символ "\" в таблице "триггер" в третьем запросе. Собственно какие конкретно символы не так важно. Главное, чтобы в таблице ASCII они шли именно в таком порядке: сначала - разделитель, потом - суффикс. Иначе нумерация не даст нужный результат и подчиненные (более длинные, продолжающиеся с разделителя) ветки не окажутся при сортировке позже Путь + "", но раньше Путь + "\" и тогда неправильно пронумеруются.
14. Alxby 477 23.08.19 20:33 Сейчас в теме
Большое спасибо за NS! Действительно, приведенные в конце статьи задачи при применении этого способа решаются довольно просто, особенно 1 и 3. Если же мы желаем «посмотреть на проблему шире, с точки зрения того, как еще можно представлять иерархию» для того, чтобы реализовать свои структуры иерархических данных, не связанных с иерархическими справочниками, то мне хотелось бы отметить несколько моментов:
1) AL: подвержен опасности появления циклов. В случае иерархического справочника за этим следит платформа, в своей реализации необходимо это делать самостоятельно. Добавление, удаление элементов, смена родителя происходит наиболее просто.
2) CT: необходимо обеспечить транзитивность отношения предок – потомок, т.е. если в ИБ хранятся пары 0001-0002 и 0002-0003, то должна быть и пара 0001-0003. Также возможно появление циклов. У элемента возможно появление нескольких непосредственных родителей. Добавление, удаление элементов, смена родителя требует пересчета всей ветки иерархии.
3) MP: циклов быть не может (если конечно в пути у элемента не будет повторяющихся кодов). Необходимо следить за соответствием путей элементов и путей родителей. Добавление, удаление элементов, смена родителя требует пересчета всех потомков этого элемента. Предъявляются повышенные требования к кодам, участвующим в образовании пути: желательно чтобы они были фиксированного размера и/или в них не должно быть символа-разделителя. Есть еще один неочевидный нюанс: часть задач при таком подходе будет решаться при помощи запросов с «LIKE» («ПОДОБНО»), а значит в кодах не должно быть «%» и «_»
4) NS: циклов быть не может. Легко «сломать» иерархию, повредив значение «Право» или «Лево» в каком-нибудь элементе. Плюсом является то, что наряду с отношением иерархии, этот метод определяет порядок элементов как внутри одного родителя, так и во всем множестве. Однако это может привести к тому, что добавление, удаление элементов, смена родителя может потребовать пересчета всего множества. Отношение подчиненности проверяется с помощью операций «больше», «меньше», что зачастую не позволит составить оптимальный запрос
ildarovich; +1 Ответить
16. ildarovich 6766 27.08.19 00:50 Сейчас в теме
(14) Очень хороший комментарий. Интересующимся данной темой обязательно нужно его прочитать. В целом согласен. То, что не для всех операций требуется контроль зацикливания или пересчет веток, и то, что есть приемы компенсации минусов каждого из представлений - это уже частности.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Программист 1С
Екатеринбург
зарплата до 120 000 руб.
Полный день

Консультант-аналитик 1С
Рязань
зарплата до 80 000 руб.
Полный день

Программист 1С
Калининград
зарплата от 60 000 руб. до 80 000 руб.
Полный день

Программист 1С
Рязань
зарплата от 90 000 руб.
Полный день