На собеседовании задали вопрос:
Есть 2 справочника оба иерархические. Один ограничен до 7 уровня вложенности, второй неограничен. В обоих одинаковое кол-во элементов. При запросе к элементу находящемуся на 3-ем уровне вложенности, для какого справочника запрос отработает быстрее?
Ответить не смог, сказали домашнее задание, но ответ так и не нашел
Есть 2 справочника оба иерархические. Один ограничен до 7 уровня вложенности, второй неограничен. В обоих одинаковое кол-во элементов. При запросе к элементу находящемуся на 3-ем уровне вложенности, для какого справочника запрос отработает быстрее?
Ответить не смог, сказали домашнее задание, но ответ так и не нашел
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Что делает "В ИЕРАРХИИ" в запросе
разбор sql
В примере выше мы видели, что платформа сгенерировала несколько запросов для получения элементов на каждом уровне иерархии. Но что, если иерархия будет содержать не 2, 3, 5 уровней, а 10, 20, 50! Чем больше уровней, тем больше запросов будет сформировано.
Что делает "В ИЕРАРХИИ" в запросе
разбор sql
В примере выше мы видели, что платформа сгенерировала несколько запросов для получения элементов на каждом уровне иерархии. Но что, если иерархия будет содержать не 2, 3, 5 уровней, а 10, 20, 50! Чем больше уровней, тем больше запросов будет сформировано.
(1) (5) Есть и другой способ обхода иерархического справочника - рекурсивный запрос.
Тут (далекий 2008 год про стандарты 1999 года) описано, когда это примерно появилось в разных SQL.
Ниже скрин набросал с условием в иерархии группы 1 (выделил в тексте).
То что делает 1С всё равно ограничено уровнем вложенности. Если до конца дочитать статью, то:
"Влияние на производительность
В примере выше мы видели, что платформа сгенерировала несколько запросов для получения элементов на каждом уровне иерархии. Но что, если иерархия будет содержать не 2, 3, 5 уровней, а 10, 20, 50! Чем больше уровней, тем больше запросов будет сформировано."
У рекурсивного запроса код короче. Если справочник содержит поле уровень, то для глубоких уровней можно ускорить время выполнение, заведомо ограничив выборку.
Нарисовал ограничение рекурсивного запроса максимальным уровнем <10 (t1.maxUr<10), но можно и увеличить. На MS SQL по умолчанию ограничение вложенности примерно 100. На других SQL по разному. Пробовал на SQLite поставить 300 - проглатывает. Но так много не нужно точно.
Время выполнения запроса в общем случае зависит по факту от данных, а не от того какое ограничение стоит у справочника.
В случае с 1С может быть два куска кода. Для справочника без ограничения может сначала определяться фактический максимальный уровень в данных и запрос более этого уровня не строится. В случае если ограничение в справочнике задано, например 7, то сразу его использовать 7 и строить запрос исходя из 7, хотя по факту в справочнике может быть всего 2. Это 1С - можно ожидать чего угодно.
В случае использования рекурсивного запроса всегда определяется данными по факту. А ограничение максимального уровня носит скорее защитный характер от кривых данных. Например в у элемента1 родитель элемент2, а у элемента2 родитель элемент1 и нужно найти все подчиненные элеметну1. Такое в справочнике 1С скорее невозможный вариант, но мало ли. И могут быть не только данные из справочника 1С, а входные откуда-то.
И да, 1С не поддерживает рекурсивные запросы в языке запросов 1С. Но и внутри при обращении к SQL не видел, что бы использовали - может плохо смотрел.
Тут (далекий 2008 год про стандарты 1999 года) описано, когда это примерно появилось в разных SQL.
Ниже скрин набросал с условием в иерархии группы 1 (выделил в тексте).
То что делает 1С всё равно ограничено уровнем вложенности. Если до конца дочитать статью, то:
"Влияние на производительность
В примере выше мы видели, что платформа сгенерировала несколько запросов для получения элементов на каждом уровне иерархии. Но что, если иерархия будет содержать не 2, 3, 5 уровней, а 10, 20, 50! Чем больше уровней, тем больше запросов будет сформировано."
У рекурсивного запроса код короче. Если справочник содержит поле уровень, то для глубоких уровней можно ускорить время выполнение, заведомо ограничив выборку.
Нарисовал ограничение рекурсивного запроса максимальным уровнем <10 (t1.maxUr<10), но можно и увеличить. На MS SQL по умолчанию ограничение вложенности примерно 100. На других SQL по разному. Пробовал на SQLite поставить 300 - проглатывает. Но так много не нужно точно.
Время выполнения запроса в общем случае зависит по факту от данных, а не от того какое ограничение стоит у справочника.
В случае с 1С может быть два куска кода. Для справочника без ограничения может сначала определяться фактический максимальный уровень в данных и запрос более этого уровня не строится. В случае если ограничение в справочнике задано, например 7, то сразу его использовать 7 и строить запрос исходя из 7, хотя по факту в справочнике может быть всего 2. Это 1С - можно ожидать чего угодно.
В случае использования рекурсивного запроса всегда определяется данными по факту. А ограничение максимального уровня носит скорее защитный характер от кривых данных. Например в у элемента1 родитель элемент2, а у элемента2 родитель элемент1 и нужно найти все подчиненные элеметну1. Такое в справочнике 1С скорее невозможный вариант, но мало ли. И могут быть не только данные из справочника 1С, а входные откуда-то.
И да, 1С не поддерживает рекурсивные запросы в языке запросов 1С. Но и внутри при обращении к SQL не видел, что бы использовали - может плохо смотрел.
Прикрепленные файлы:
Если отбросить вариант "ну, мы так видим", то это стандартный вопрос, направленный не на получение верного ответа, а на демонстрируемые умения его находить. О чем намекает фраза "домашнее задание".
Не претендую ни на что умное, но в этом случае можно посмотреть:
- а, вообще, у кандидата есть на его личном компьютере этот самый 1С + СУБД, нет, он не обязан это иметь.
Просто можно, нет не понять, раскидываться понятиями по одному факту, это, мягко говоря, глупо, но только прикинуть вероятность того, что ему вообще интересен 1С.
- умение не теряться, не включать студента: "ну кто его знает, что там 1С делает".
"И, вообще, у меня лапки".
- умение пользоваться тех. журналом, а то и, страшно сказать, профайлером
- умения читать план выполнения запроса
- умение создавать массивы тестовых данных, хотя бы понимать, что не на 100 строках это надо смотреть.
Что кэш надо греть и т.п.
- если позиция на что-то серьезное, то, как пример, посмотреть на то будет ли кандидат умничать про что-то типа hierarchyid (я, кстати, про это понятия не имел, только сейчас нагуглил, но нагуглил же и даже понял как ентим пользоваться :) ).
- а может кандидат предложит более эффективный запрос к иерархическим данным? Заодно можно посмотреть на стиль кодирования.
Или проявит сообразительность и покажет умение пользоваться ChatGPT -уши этого, конечно, вылезут, но в данном случае, это хорошо.
- а может не кинется что-то решать, а будет задавать уточняющие вопросы про версию платформу, вид и версию СУБД, по какому типу поля будет строится иерархия и т.п. Может тогда его надо на архитектора?
Словом, обычная задачка типа "сколько нужно бензоколонок в городе Сплит".
Можно на такой вопрос сразу послать, и вас, возможно, не прогонят просто вместо старшего менеджера по что-то там в носу, предложат должность бухгалтера.
Не претендую ни на что умное, но в этом случае можно посмотреть:
- а, вообще, у кандидата есть на его личном компьютере этот самый 1С + СУБД, нет, он не обязан это иметь.
Просто можно, нет не понять, раскидываться понятиями по одному факту, это, мягко говоря, глупо, но только прикинуть вероятность того, что ему вообще интересен 1С.
- умение не теряться, не включать студента: "ну кто его знает, что там 1С делает".
"И, вообще, у меня лапки".
- умение пользоваться тех. журналом, а то и, страшно сказать, профайлером
- умения читать план выполнения запроса
- умение создавать массивы тестовых данных, хотя бы понимать, что не на 100 строках это надо смотреть.
Что кэш надо греть и т.п.
- если позиция на что-то серьезное, то, как пример, посмотреть на то будет ли кандидат умничать про что-то типа hierarchyid (я, кстати, про это понятия не имел, только сейчас нагуглил, но нагуглил же и даже понял как ентим пользоваться :) ).
- а может кандидат предложит более эффективный запрос к иерархическим данным? Заодно можно посмотреть на стиль кодирования.
Или проявит сообразительность и покажет умение пользоваться ChatGPT -уши этого, конечно, вылезут, но в данном случае, это хорошо.
- а может не кинется что-то решать, а будет задавать уточняющие вопросы про версию платформу, вид и версию СУБД, по какому типу поля будет строится иерархия и т.п. Может тогда его надо на архитектора?
Словом, обычная задачка типа "сколько нужно бензоколонок в городе Сплит".
Можно на такой вопрос сразу послать, и вас, возможно, не прогонят просто вместо старшего менеджера по что-то там в носу, предложат должность бухгалтера.
(14)
Всего должно быть в меру. А задачи для ЧСВ - ну пусть будут, как задачи со звездочкой. А то можно спросить и про хешфункцию. для паролей пользователей 1С, но с какой-то следующей платформы их будет уже больше одного, но знаю, что народ и такое спрашивает)...
оставшиеся 20
D 1C сейчас много стало разделения труда. Кто-то оптимизацией занимается, кто-то девопсом (что бы это ни значило в конкретной организации), кто-то разъехался по подсистемам, кто-то остался "фуллстек". Если конторе нужен спец уровня решения проблем производительности, то ему можно такие вопросы задавать, а он может сказать, что давайте профайлер откроем и поглядим. А если это просто кодер-универсал, то ему достаточно задать вопросы о бестпрактис работы с запросами (не злоупотребляйте временными, не соединяйтесь с виртуальными, соединяйтесь по индексам, используйте ВЫРАЗИТЬ для разыменовывания составных полей, ...) и выяснить понимание того, как платформа кеширует объекты (ПолучитьЗначениеРеквизитов против разыменовывания для обращения к свойствам).
Всего должно быть в меру. А задачи для ЧСВ - ну пусть будут, как задачи со звездочкой. А то можно спросить и про хешфункцию. для паролей пользователей 1С, но с какой-то следующей платформы их будет уже больше одного, но знаю, что народ и такое спрашивает)...
(15) Мне кажется, но есть вещи, которые любой программист должен понимать, а не следовать им потому, что это the best practices.
Я уже не говорю про то, что на них еще и мода влияет, вспомните как singleton разжаловали в антипатерн (ну да, причины возникли, всякие там сложности с тестированием и многопоточностью, но все же)
Вопрос, где следует остановится, ибо это уже другая ветвь.
Знание, на уровне СУБД, типа и вида блокировок, частоты попадания в индексы, пользования всякими там grep и прочими страшными вещами, умение выгрузить практически не рабочий журнал 1С в elastic ... Ну да, тут можно сказать "я об этом подумаю завтра".
Но вот хотя бы понимать, что такое селективность индекса, какие именно ресурсы задействуют временные таблицы, что происходит с базой при удалении записей из таблиц вне транзакции и с оной и т.п.
Ну это же надо всем, разве нет?
Встречаю постоянно темы:
- мне надо удалить 100500 записей, а оно виснет,
- "а вот какой замечательный запрос сгенерировал ChatGPT", приводя в пример поиск по не индексированному строковому полю/полям, да еще и ненадежный.
Я уже не говорю про то, что на них еще и мода влияет, вспомните как singleton разжаловали в антипатерн (ну да, причины возникли, всякие там сложности с тестированием и многопоточностью, но все же)
Вопрос, где следует остановится, ибо это уже другая ветвь.
Знание, на уровне СУБД, типа и вида блокировок, частоты попадания в индексы, пользования всякими там grep и прочими страшными вещами, умение выгрузить практически не рабочий журнал 1С в elastic ... Ну да, тут можно сказать "я об этом подумаю завтра".
Но вот хотя бы понимать, что такое селективность индекса, какие именно ресурсы задействуют временные таблицы, что происходит с базой при удалении записей из таблиц вне транзакции и с оной и т.п.
Ну это же надо всем, разве нет?
Встречаю постоянно темы:
- мне надо удалить 100500 записей, а оно виснет,
- "а вот какой замечательный запрос сгенерировал ChatGPT", приводя в пример поиск по не индексированному строковому полю/полям, да еще и ненадежный.
Опытный рекрутер в курсе, что многие некоторые программисты склонный впадать в перфекционизм. Это когда необходимо решить задачу бизнеса здесь и сейчас, а он сидит штрифты/рамочки выбирает)
Думаю, это был вопрос на степень перфекционизма. Правильный ответ: по условиям задачи результаты будут практически равны, а если вам нужны теоретические выкладки из профайлера, то давайте обсудим кто мне оплатит время на дополнительные исследования, не существенные для вашего бизнеса.
Думаю, это был вопрос на степень перфекционизма. Правильный ответ: по условиям задачи результаты будут практически равны, а если вам нужны теоретические выкладки из профайлера, то давайте обсудим кто мне оплатит время на дополнительные исследования, не существенные для вашего бизнеса.
Я вот не понимаю о чем спорите.
Текст вопроса:
Прямой запрос к элементу. Какая разница, есть у него ограничение уровней иерархии или нет. Да хоть в сравнении с неиерархическим. Запрос к плоской таблице напрямую к ссылке. Вообще не будет разницы.
Текст вопроса:
При запросе к элементу находящемуся на 3-ем уровне вложенности, для какого справочника запрос отработает быстрее?
Прямой запрос к элементу. Какая разница, есть у него ограничение уровней иерархии или нет. Да хоть в сравнении с неиерархическим. Запрос к плоской таблице напрямую к ссылке. Вообще не будет разницы.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот