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

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

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

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

Комментарии
Избранное Подписка Сортировка: Древо
1. PerlAmutor 46 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 46 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 46 23.08.19 19:56 Сейчас в теме
(6) В справочнике - да. Мне хочется иерархический регистр, чтобы без пометок на удаление, с возможностью перестроения деревьев в любой момент без контроля ссылочной целостности.
8. Rustig 1206 23.08.19 09:31 Сейчас в теме
(4) для таких задач создаете свои промежуточные таблицы, которые постоянно обновляются по определенным событиям. и не надо тогда будет использовать сложные запросы. универсального решения нет, под каждую задачу создаете свой механизм и логику. что-то подобное я описал здесь https://infostart.ru/public/195627/
2. Поручик 4334 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 1206 23.08.19 09:33 Сейчас в теме
(7) не читая? уровень сложности статей 10 баллов из 10.... не все дочитают до конца, и не все поймут...
user774630; +1 Ответить
10. DarkAn 902 23.08.19 10:19 Сейчас в теме
(9) может и 10 и 11, пофиг. Главное, что читающий хочет в статье почерпнуть?

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

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

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

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

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

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

Еще из важных мелких деталей, которые нужно не забыть добавить в статью, это символ разделителя "/" и символ "\" в таблице "триггер" в третьем запросе. Собственно какие конкретно символы не так важно. Главное, чтобы в таблице ASCII они шли именно в таком порядке: сначала - разделитель, потом - суффикс. Иначе нумерация не даст нужный результат и подчиненные (более длинные, продолжающиеся с разделителя) ветки не окажутся при сортировке позже Путь + "", но раньше Путь + "\" и тогда неправильно пронумеруются.
14. Alxby 475 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 6751 27.08.19 00:50 Сейчас в теме
(14) Очень хороший комментарий. Интересующимся данной темой обязательно нужно его прочитать. В целом согласен. То, что не для всех операций требуется контроль зацикливания или пересчет веток, и то, что есть приемы компенсации минусов каждого из представлений - это уже частности.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

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

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

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день