Планы запросов - это просто!

Публикация № 643479

Администрирование - Производительность и оптимизация (HighLoad)

план запроса оптимизация

Наверное, каждый 1С-ник задавался вопросом "что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"? В данной статье я не дам вам исчерпывающих инструкций по чтению планов запроса. Но я постараюсь объяснить доходчиво - что это такое и с какой стороны к ним подойти.

Введение

Наверное, каждый 1С-ник задавался вопросом "что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"?

После чего 1С-ник идет на форум, а там ему говорят - надо смотреть план запроса. Он смотрит, и ничего не понимая, навсегда забрасывает идею оптимизации запросов через планы, продолжая сравнивать варианты простым замером производительности.

В результате, на машине разработчика запрос начинает просто летать, а затем в боевой базе при увеличении количества записей все умирает и начинаются жалобы в стиле "1С тормозит". Знакомая картинка, не правда ли?

В данной статье я не дам вам исчерпывающих инструкций по чтению планов запроса. Но я постараюсь объяснить доходчиво - что это такое и с какой стороны к ним подойти.

Более того, я не считаю себя хорошим оптимизатором запросов, поэтому, в статье весьма вероятны фактологические косяки. Ну тут пусть гуру меня поправят в каментах. На то мы тут и сообщество, чтобы помогать друг-другу, верно? 

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

Как работает компьютер

А начну я издалека. Дело в том, что компьютеры, к которым мы привыкли, они не такие уж и умные. Вы же наверняка помните первые уроки информатики, или младшие курсы ВУЗа? Помните сортировку массивов пузырьком там, или чтение файла построчно? Так вот, принципиально нового ничего не изобретено в современных реляционных СУБД. 

Если на лабораторках вы считывали строчки из файла, а потом записывали их в другое место, то вы уже примерно представляете, как работает современная СУБД. Да, разумеется, там все намного (совсем намного) сложнее, но - циклы они и в Африке циклы, чтение диска все еще не стало быстрее чтения ОЗУ, а алгоритмы O(N) все еще медленнее алгоритмов O(1) при увеличении N. 

Давайте представим, что к вам, простому 1С-нику пришел человек и говорит: "смотри, дружище, надо написать базу данных. Вот тут файл, в нем строчки какие-нибудь пиши. А потом оттуда читай". Представим, что отказаться вы не можете. Как бы вы решали эту задачу? 

А решали бы вы ее точно так же, как решают ее ребята из Microsoft, Oracle, Postgres и 1С. Вы бы открыли файл средствами вашего языка программирования, прочитали бы оттуда строки и вывели бы их на экран. Никаких принципиально отличных алгоритмов, от тех, что я уже описал - мир не придумал. 

Представьте, что у вас есть 2 файла. В одном записаны контрагенты, а в другом - договоры контрагентов. Как бы вы реализовывали операцию ВНУТРЕННЕЕ СОЕДИНЕНИЕ? Вот прямо в лоб, без каких-либо оптимизаций? 

Контрагенты

ID

Имя

1

Петров

2

Иванов

3

Сидоров

 

Договоры

ID

IDКонтрагента

НомерДоговора

1

1

ИК-1002399

2

1

БМ-0010/УУ

3

2

Счет 09200

 

Давайте сейчас для простоты опустим нюансы открывания файлов и чтения в память. Сосредоточимся на операции соединения. Как бы вы его делали? Я бы делал так:

Для Каждого СтрокаКонтрагент Из Контрагенты Цикл
    Для Каждого СтрокаДоговор Из Договоры Цикл
        Если СтрокаДоговор.IDКонтрагента = СтрокаКонтрагент.ID Тогда
            ВывестиРезультатСоединения(СтрокаКонтрагент, СтрокаДоговор);
        КонецЕсли;
    КонецЦикла;
КонецЦикла;
 

В примере ф-я ВывестиРезультатСоединения просто выведет на экран все колонки из переданных строк. Ее код здесь не существенен. 

Итак, мы видим два вложенных цикла. Внешний по одной таблице, а потом во внутреннем - поиск ключа из внешней простым перебором. А теперь, внезапно, если вы откроете план какого-нибудь запроса с СОЕДИНЕНИЕМ в любой из 1С-ных СУБД, то с довольно высокой вероятностью увидите там конструкцию "Nested Loops". Если перевести это с языка вероятного противника на наш, то получится "Вложенные циклы". То есть, в "плане запроса" СУБД вам объясняет, что вот тут, для "соединения" она применила алгоритм, описанный выше. Этот алгоритм способен написать любой школьник примерно 7-го класса. И мощные боевые СУБД мирового уровня применяют этот алгоритм совершенно спокойно. Ибо в некоторых ситуациях - он лучшее, что есть вообще. 

И вообще, чего это я сразу с "соединения" начал. Давайте предположим, что вам нужно просто найти контрагента по наименованию. Как бы вы решали эту задачу? Вот есть у вас файл с контрагентами. Напишите алгоритм. Я напишу его вот так:

Для Каждого СтрокаКонтрагент Из Контрагенты Цикл
    Если СтрокаКонтрагент.Имя = "Иванов" Тогда
        ВывестиРезультат(СтрокаКонтрагент);
    КонецЕсли;
КонецЦикла;

Нет, ну серьезно, а как еще его можно написать? А никак по сути. Если неизвестно в каком порядке лежат записи в таблице, то придется пересмотреть ее всю, как ни крути. На языке планов запроса это называется Scan. Сканирование. Полный просмотр данных и ничего больше.

Индексы

А как же мы можем ускорить поиск данных в таблице? Ну правда, всё время пересматривать всё - это же зло какое-то.  

Вспомним картотеку в поликлинике или библиотеке. Как там выполняется поиск по фамилии клиента? В деревянных шкафчиках стоят аккуратные карточки с буквами от А до Я. И пациент "Пупкин" находится в шкафчике с карточкой "П". Просматривать подряд все прочие буквы нет необходимости. Если мы отсортируем данные в нашей таблице и будем знать, где у нас (под какими номерами строк) находятся записи на букву "П", то мы существенно приблизимся к быстродействию тетеньки из регистратуры. А это уже лучше, чем полный перебор, не так ли?  

Так вот, слово "Индекс" в данном контексте означает (опять же, в переводе с языка вероятного противника) "Оглавление". Чтобы быстро найти главу в книге, вы идете в оглавление, находите там название главы, потом смотрите номер страницы и идёте сразу на эту страницу. 

Когда базе данных нужно найти запись в таблице, она идет в оглавление, смотрит на название контрагента, смотрит на номер записи, под которой он лежит, и идет в нужную область файла данных сразу за этой записью. 

В виде кода это может выглядеть примерно так:  

Индекс = Новый Соответствие;

// бла-бла

НомерЗаписи = Индекс["Иванов"]
ВывестиРезультат(ТаблицаКонтрагентов[НомерЗаписи]);

Известно, что чудес не бывает, поэтому, память под Соответствие "Индекс", а также поиск в самом соответствии - это небесплатные операции. Но они намного дешевле, чем прямой перебор всех данных. Ах, да, это Соответствие придется постоянно поддерживать в актуальном состоянии при добавлении или изменении основных данных. 

Теперь давайте подумаем, а как бы вы реализовывали сам этот индекс? Можно хранить записи в файле данных сразу в отсортированном виде. И все бы ничего, но, во-первых, искать надо каждый раз по разным полям, а во-вторых, если в уже заполненную от А до Я таблицу пользователь захочет вставить запись на букву М? А ведь он захочет, я вас уверяю.  

Вспомним, как вообще ведется запись в файл. 

fseek(file, position); // переход к нужному адресу
write(file, dataArray, dataLength); // запись dataLength байт из массива dataArray

Если адрес position указывает куда-то в середину файла, и на этом месте есть данные, то они затираются новыми. Если нужно вставить что-то в середину файла (и массива в памяти в том числе) то нужно в явном виде "подвинуть" все, что находится после position, освободив место, а уже потом писать новые данные. Как вы понимаете, "подвижка" данных это опять же циклы и операции ввода/вывода. То есть, не так уж быстро. Ничего в компьютере "само" не происходит. Все по команде. 

Вернемся к индексу. Пользователь хочет вставить что-то в середину. Хочешь не хочешь, а придется двигать данные, либо исхитряться с хранением данных в "страницах", связанных между собой в список. Физически писать в конец, или в пустое место, но как будто в середину таблицы. И потом еще обновлять в оглавлении номера записей. Они же теперь сдвинулись и индекс показывает не туда куда нужно. Вы, наверное, слышали, что индексы в БД ускоряют поиск, но замедляют вставку и удаление. Теперь, вы знаете, почему это так. 

Ну так вот, мы еще не решили проблему поиска по разным полям. Мы же не можем хранить данные в файле в разном порядке. Одному пользователю по имени, а другому, скажем - по дате. Причем одновременно. Как бы вы решали эту задачу? По-моему, решение очевидно - нужно хранить отдельно данные и отдельно оглавления, отсортированные по нужным полям. Т.е. в базе данные лежат, как придется, но рядышком мы создадим файлик, где записи отсортированы по имени. Это будет индекс по полю "Имя". А еще рядышком будет другой такой же файлик, но отсортированный по полю "Дата". Для экономии места мы будем хранить в индексах не все колонки основной таблицы, а только те, по которым выполнена сортировка (чтобы быстро тут искать, находить номер записи и моментально прыгать к ней, чтоб прочитать остальные данные).

Ребята, которые пишут взрослые СУБД тоже не придумали ничего лучше. Индексы в БД устроены именно так. Все данные из таблицы лежат отсортированными рядышком в отдельной сущности. По сути, индекс, это просто еще одна таблица. И места она занимает пропорционально размеру основной таблицы, что логично. Да, там еще есть разные ухищрения, типа сбалансированных деревьев и всякого такого, но смысл не сильно меняется. 

Кстати, если записывать данные в основную таблицу сразу упорядоченными, то можно не делать отдельно хранимый индекс и считать индексом саму таблицу с данными. Здорово, правда? Такой индекс называют "кластерным". Логично, что поле, по которому отсортированы записи в таблице должно стараться монотонно нарастать. Вы же помните про вставку в середину, верно?

Планирование выполнения запроса

Представьте, что у вас таблица в пять миллионов записей. И есть у нее индекс. Надо быстренько найти запись со словом "Привет". А еще представьте, что у вас такая же таблица, но с тремя записями. И тоже надо найти "Привет". Какой способ поиска выбрать? Открыть файл индекса, пробежаться по нему двоичным поиском, найти нужный номер записи, открыть файл основной таблицы, перейти к записи по ее номеру, прочитать ее? Или запустить цикл от одного до трех, проверив каждую запись на соответствие условию? Современный компьютер циклы от одного до трех выполняет просто ужас, как быстро.  

Чтобы принять решение, планировщик запроса должен понимать, с чем имеет дело. Он оперирует такой штукой, как статистика. Статистика включает в себя количество записей по таблицам, распределение данных по колонкам, селективность и прочее и прочее. Это все подсказки планировщику о том, какой способ сбора данных будет быстрее. Не самым быстрым из возможных, а хотя бы достаточно быстрым с некоторой вероятностью. И у планировщика ограничено время на принятие решения. мы же хотим быстро получить данные, а не ждать, пока он там планирует себе. 

Вот тут уже я бы не стал браться за работу по написанию планировщика, не защитив предварительно диссертацию. Как он там работает и как умудряется делать это вполне сносно - не знаю. Поэтому, ограничимся документацией СУБД. Из нее следует, что на основании статистики планировщик строит несколько возможных вариантов пошагового выполнения запроса, а потом выбирает из них наиболее подходящий. Например, первый попавшийся. Тоже ведь эвристика, разве нет? 

"Что мне сделать сначала" - думает планировщик: "обойти всю таблицу А, отобрав записи по условию, а потом соединить с таблицей Б вложенными циклами, или же найти индексом все подходящие записи таблицы Б, а уже потом пробежаться по таблице А"? Каждый из шагов имеет определенный вес или стоимость. Чем больше стоимость, тем сложнее выполнять. В плане запросов всегда написана стоимость каждого из шагов, которые выполнил движок СУБД, чтобы собрать результаты запроса.

Устройство оператора плана

Каждый шаг плана запроса реализован в виде некоторого объекта, на вход которого подается одно множество записей, а на выходе получается другое. Если представить это в виде кода, то получится, что оператор плана запросов представляет собой реализацию абстрактного интерфейса с одним методом: 

interface IQueryOperator {
    DataRow GetNextRow();
}

для тех кто не понял, что тут написано, поясню. Каждый оператор плана запросов имеет метод "ДайСледующуюЗапись". Движок СУБД дергает оператор за этот метод и при каждом таком дергании добавляет полученную запись к результату запроса. Например, оператор фильтрации записей на входе имеет всю таблицу, а на выходе - только те, которые удовлетворяют условию. Далее, выход этого оператора подается на оператор, например, ПЕРВЫЕ 100, а далее на оператор агрегации (СУММА или КОЛИЧЕСТВО), которые точно так же, внутри инкапсулируют всю обработку, а на выход выдают запись с результатом.

Схематично это выглядит так:

ВсеДанные ->Фильтр(Имя="Петров")->Первые(100)->Аггрегация(КОЛИЧЕСТВО)

Когда вы откроете план запроса, то увидите кубики, соединенные стрелочками. Кубики - это операторы. Стрелочки - направление потоков данных. Данные бегут по стрелочкам от одного оператора к другому, сливаясь в конце в результат запроса.

Каждый оператор имеет некие параметры: количество обработанных записей, стоимость, количество операций ввода/вывода, использование кэшей и прочее и прочее. Все это позволяет судить об эффективности выполнения запроса. Scan таблицы, пробежавший миллион записей и выдавший две на выходе - это не очень хороший план запроса. Но лучше планировщик ничего не нашел. У него не было индекса, чтобы поискать в нем. А может, наврала статистика и сказала, что в таблице три записи, а на самом деле туда успели написать миллион штук, но статистику не обновили. Все это предмет для разбирательства инженером, который изучает запрос.

План запроса - это пошаговый отладчик запроса. Вы пошагово смотрите, что именно, какой алгоритм (в буквальном смысле) применила СУБД, чтобы выдать результат. Примеры самих алгоритмов вы видели - они чрезвычайно сложны, ведь там есть циклы и условия. Даже порой несколько циклов вложены, вот ведь ужас. Важно понимать, какие процессы происходят внутри каждого оператора. Какой алгоритм применялся к массиву записей в процессе выполнения и сколько он работал.

Конкретные операторы, встречающиеся в планах запроса и их внутреннее устройство я планирую рассмотреть в следующей статье. Спасибо за то, что прочитали до конца!

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. spezc 655 04.07.17 03:35 Сейчас в теме
В принципе интересно написано)
Manoshkin; +1 Ответить
2. rusmil 209 04.07.17 08:13 Сейчас в теме
Спасибо, написано очень доступно для понимания
frkbvfnjh; Bazil; +2 Ответить
3. DenisCh 04.07.17 08:29 Сейчас в теме
написано живенько, для новичков вполне подойдёт
andron77777; theelectric; Silenser; +3 Ответить
4. vasilev2015 1829 04.07.17 09:14 Сейчас в теме
я тоже пытался раскрыть тему скорости соединений http://infostart.ru/public/534444/
Но что-то пошло не так )))

Надеюсь, Андрею повезет больше. Удачи.
Evil Beaver; +1 Ответить
5. Famza 83 04.07.17 09:27 Сейчас в теме
опять же, в переводе с языка вероятного противника

Зачет!
RussXXX; NN2P; theelectric; herfis; DarkUser; pozdeev-artem; корум; artbear; +8 Ответить
6. asved.ru 35 04.07.17 09:44 Сейчас в теме
Самое главное упущено:

Большая часть операторов плана работает построчно, т.е. для того, чтобы вернуть первую строку, им достаточно получить от нижестоящего оператора одну строку, подходящую по условиям.
Однако некоторым операторам для возврата первой строки необходимы все строки, возвращаемые предыдущим оператором. Это Sort (Что логично, пока мы не получим последнюю строку, мы не можем завершить сортировку), это для одного из наборов строк - Hash join и т.п.

Т.е. когда мы видим оператор Sort в запросе динамического списка - можно начинать ругаться не глядя :)
В последних версиях платформы, кстати, добавили ограничение на использование полей для сортировки списков. Вот именно по этой причине.
Kinestetik; _LYNX; sulfur17; brr; +4 Ответить
8. Evil Beaver 6755 04.07.17 09:49 Сейчас в теме
(6)отчего же упущено? Написано же: на входе одно множество, на выходе - другое. Сортировка сюда подходит.
16. asved.ru 35 04.07.17 13:42 Сейчас в теме
(8) вопрос в том, сколько строк будет прочитано для получения множества, ограниченного TOP.
7. asved.ru 35 04.07.17 09:45 Сейчас в теме
А вот неплохой доклад по теме:
https://www.youtube.com/watch?v=4yHc8-Idf-w
Skopoxod; logarifm; Kinestetik; Zircool; sulfur17; herfis; jif; Evil Beaver; +8 Ответить
9. Новиков 291 04.07.17 10:13 Сейчас в теме
Мне кажется, для 1сника будет интересен также ответ на вопрос: что происходит в субд, когда он жмет F5 (или какую-то другую команду на выполнение) в среде исполнения запроса. По MS SQL такой инфы с нуля я не находил. По PostgreSQL есть шикардосная статья: Путешествие запроса Select через внутренности Постгреса
user811769; _LYNX; sulfur17; artbear; Evil Beaver; +5 Ответить
10. brr 179 04.07.17 10:50 Сейчас в теме
Спасибо, как раз хотел объяснить дочери (4 класс) реляционные базы, она интересовалась, текст как основа подойдет. "Быстродействие тетеньки из регистратуры" это пять.
NN2P; rovenko.n; корум; +3 Ответить
11. swimdog 713 04.07.17 10:55 Сейчас в теме
Статью не читал, но имею сказать по существу) "Наверное, каждый 1С-ник задавался вопросом "что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"?" - лучше чем проверка разных вариантов практически, ничего нет. Один и тот же запрос на разных базах может работать по разному. Например, в одной базе номенклатуры 1000, а в другой 100000. И хорошо работающий запрос из базы с небольшой номенклатурой будет дико тормозить в другой базе. Но если вы не писатель типовых программ или отраслевых решений, то достаточно замеров времени выполнения на вашей конкретной базе. А для понимания работы запросов советую курсы. Они быстрее помогут разобраться новичкам, как писать текст запросов, чем копание в планах запроса. Это совет, но ни в коем случае не отрицательный отзыв на статью!
12. Evil Beaver 6755 04.07.17 11:15 Сейчас в теме
(11)
Статью не читал... хорошо работающий запрос из базы с небольшой номенклатурой будет дико тормозить в другой базе...достаточно замеров времени выполнения...чем копание в планах запроса


Вот это я прямо в рамочку поставлю!
RickyTickyTok; user811769; RFP; mikeA; haereticus; acanta; zarucheisky; sasha777666; Dementor; JohnyDeath; Бубузяка; DeD MustDie; корум; Sergey.Noskov; Новиков; artbear; +16 Ответить
19. swimdog 713 04.07.17 14:49 Сейчас в теме
(12) 1) Идея была в другом. Сначала набрать основу, как правильно писать запросы, а потом лезть внутрь SQL. Набрать основу проще всего: 1) на курсах 2) читая статьи на ИТС или спецресурсах 3) спрашивая на форумах. Поэтому я предложил сначала получить базу на курсах.
2) Я могу предположить, что план запросов в разных базах будет разным, даже в зависимости от наполнения таблиц, статистики и прочего. И план запроса может также ввести в заблуждение, как и замер времени на пустой базе.
3) Для простых случаев не вижу ничего плохого в использовании замера времени. Вот когда замеры вопроса не решают, тогда да. Тогда и КИП лишним не будет.
53. ArchLord42 73 06.10.17 05:15 Сейчас в теме
(11) по секрету вам скажу, изучив планы запроса несколько раз, через какое-то время, вы начнете писать запросы, которые будут одинакого быстро работать в разных базах с первого раза! только тссс...
55. swimdog 713 06.10.17 10:56 Сейчас в теме
(53) Только недавно пришлось разбираться в плане запросов, так как все остальное себя исчерпало. Но то ли я дурак, то ли лыжа не едут)) Ничем мне не помогла портянка запроса в терминах SQL. Да, я увидел, что совсем криминального там ничего нет, но причины зависания запросов я так и не нашел. В результате максимально выкинул все возможное и ограничив оставшееся через "выразить". Тогда запрос начал работать стабильнее.
В общем, пока остался при своем мнении, что план запроса последняя мера. По крайней мере для меня, в сегодняшних реалиях.
56. ArchLord42 73 06.10.17 16:12 Сейчас в теме
(55)
Ну уж ограничить лишние запросы к составному реквизиту это пожалуй "маст хев" для более менее больших, возможно в будущем больших таблиц, тут даже в план не надо лезть :)
А вообще есть в инете много инфы как работать с планом запроса и профайлером, ну и советую курс от Гилева по подготовке к 1с эксперту, сам его проходил, там очень много посвящено работе с планом запроса и как раз много практических примеров.
13. FreeArcher 96 04.07.17 11:49 Сейчас в теме
Я, даже как знакомый с планами запросов, прочитал с удовольствием и открыл для себя даже новое (я например думал что СУБД гораздо умнее).
Вобщем очень хорошо информация ложится в голову с такими простыми примерами.
Автору спасибо!
EugeneSemyonov; juker; +2 Ответить
14. artbear 1184 04.07.17 12:12 Сейчас в теме
(0) Очередная отличная юморная статья от владельца статуэтки Инфостарт :)
wowik; zarucheisky; kuzyara; +3 Ответить
20. Evil Beaver 6755 04.07.17 15:05 Сейчас в теме
(14) это не статуэтка, а параллелепипед )
15. kolya_tlt 23 04.07.17 12:14 Сейчас в теме
Хорошая статья, но кажется не законченной, так как всё равно нет ответа на поставленной вопрос:
"что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"?
17. asved.ru 35 04.07.17 13:43 Сейчас в теме
(15) Ответа на этот вопрос не существует: сам вопрос поставлен некорректно.
Кстати, в случае достаточно простых условий план для этих вариантов будет один и тот же.
Evil Beaver; +1 Ответить
18. sommid 04.07.17 14:43 Сейчас в теме
спасибо, ждем-с продолжения
21. swimdog 713 04.07.17 15:17 Сейчас в теме
22. starik-2005 2177 04.07.17 15:18 Сейчас в теме
Дочитал до nested loops, пришла мысль, что автор недопонимает, но осилил дочитать до конца, после чего понял, что нужно дочитывать до конца.
Dementor; DeD MustDie; корум; +3 Ответить
23. Evil Beaver 6755 04.07.17 15:52 Сейчас в теме
(22) прочитал комментарий до конца. Два раза, после чего, так и не понял, это была критика или одобрение?
корум; brr; +2 Ответить
24. starik-2005 2177 04.07.17 15:55 Сейчас в теме
(23)
это была критика или одобрение?
Как сказала наш тренер по публичным выступлениям и работе с аудиторией, что если чувства после реплики противоречивые, то однозначно вами манипулируют!
25. HAMMER_59 206 05.07.17 07:05 Сейчас в теме
Какой кошмар написан про индексы, ведь полно статей на инфостарте, где все правильно расписано.
"Пользователь захочет записать в середину индекса" придётся всё двигать? Какой ужас.
Еще в начале статьи написано, что дальше массивов никуда не ушли. А как же STL, как же списки, очереди?
Индексы хранятся в виде бинарных деревьев: во первых хранятся блоками, где заранее предусмотрено место под вставку, во вторых передвинуть блок в дереве не проблема, проблема - сбалансировать дерево.
26. Evil Beaver 6755 05.07.17 07:31 Сейчас в теме
(25) а вам не пришло в голову, что это необходимое упрощение?

Ну и про STL посмеялся, спасибо. На дрсуге подумайте, как реализованы ваши списки и очереди.
juker; sasha777666; artbear; starik-2005; +4 Ответить
29. HAMMER_59 206 05.07.17 12:32 Сейчас в теме
(26) Может Вам лучше всё-таки узнать как утроены деревья, а не смеяться на тем чего не знаете? Я Вам конкретно указал, что не существует выдуманной Вами проблемы вставки элемента в середину дерева. Списки, деревья, каталоги, очереди - это уже совсем не массивы, про которые Вам рассказали в школе. Стандартная библиотека шаблонов, довольно, кардинально изменила подход в работе с данными.

Необходимое упрощение? Т.е. эта такая мелочь, что именно с помощью индексов достигается масштабируемость?

Лично я не вижу смысла заглядывать в план построения запроса, не беспокоитесь заглядывал, просто не вижу в этом никакого смысла, когда задачу можно решить куда более простым путём.

Консоль запросов - умеет замерять затраты на отдельные части запроса. Видим, в каком месте проблема, а проблема всегда в одном - не используются индексы. И разбираемся почему не используются, как правило, запрос написан так, что SQL или другой СУБД слишком сложно разобрать запрос. Проблема решается, как правило, дроблением огромного запроса, на несколько мелких.

Также нужно понимать, какие индексы строит 1С, что местами не очень очевидно, например в случае с периодическими регистрами сведений, мало того, концепция построения индекса для периодического регистра сведений различная, для различный версий программных файлов.

Подытожим:
Какой смысл заглядывать в план построения запроса? Чтобы найти узкое место? Так его можно найти намного проще.
В статье написано, что вот мол на маленькой базе всё нормально, а при большом количестве данных начинает всё тормозить. Т.е. заранее сможете по плану построения запроса сделать прогнозы? Так это враньё, т.к. лишний раз СУБД не будет использовать индексные файлы, и план построения запроса будет зависеть от состояния БД, мало того ещё и от статистики будет зависеть.
35. Evil Beaver 6755 05.07.17 18:03 Сейчас в теме
(29)
выдуманной Вами проблемы вставки элемента в середину дерева


Я такого не писал. Я писал о невыдуманной мной проблеме вставки в середину файла. И написал, как она решается. Кроме того, сбалансированные деревья я также упомянул.

И это необходимое для данного уровня упрощение. Основной тезис которого, что вставка в середину индекса - дорогая операция, а индексы - занимают место, поскольку это не какой-то волшебный булев признак, а полноценная сущность, являющаяся проекцией данных самой таблицы.

Поверьте, довольно большой процент "программистов 1С" на собеседованиях не знает даже этого. У них есть мантра "включить индексирование", а что это и зачем, и как вообще выглядит - не знают.
30. HAMMER_59 206 05.07.17 12:56 Сейчас в теме
(26)
Да собственно в чем проблема, долго пример списка привести, все остальные объекты (деревья, очереди, словари и т.д.) подобны списку.

Для списка мы храним ссылку на первый элемент, в случае пустого списка храним NULL.

Каждый элемент, хранит
- Ссылку на данные.
- Ссылку на следующий элемент списка. Последний элемент хранит NULL.

В чём проблема вставить элемент в середину списка? Сколько это займёт времени?
31. starik-2005 2177 05.07.17 13:19 Сейчас в теме
(30)
В чём проблема вставить элемент в середину списка?
Всегда интересовался, как в таком списке найти некий элемент X. Приведите пример его поиска, отличного от scan.
Evil Beaver; sasha777666; +2 Ответить
33. HAMMER_59 206 05.07.17 14:28 Сейчас в теме
(31)
На Си со времен института не писал, могу ошибаться в названии объектов.
Создаём MultiSet, в этот объект добавляем ключ (реквизит по которому будем осуществлять поиск), и ссылку на элемент списка. Собственно индексы подобным образом и работают.
А поиск по MultiSet очень быстро отработает.

Говоря языком 1С, то же самое что добавить индекс к таблице значений.
34. starik-2005 2177 05.07.17 15:59 Сейчас в теме
(33)
А поиск по MultiSet очень быстро отработает.
Тут есть одна проблема: когда мы добавляем индекс, то нам нужно при вставке каждый раз этот индекс расщеплять на часть до и часть после. Вот есть у Вас тот мультисет - это просто список с хештаблицей к элементам, полагаю. Вот добавили вы его - и вроде все хорошо, добавился элемент. Но дальше вам нужно этот индекс сохранить - это запись. Допустим у Вас есть какая-то недозанятая страница и Вы просто в нее пишите. Если вставлять подряд кучу данных, то однажды незанятые страницы закончатся и нужно будет какую-то страницу расщеплять на две, в итоге будут две наполовину пустые страницы. Но при этом в саму таблицу Вы вставляете элементы в конец и не особо паритесь с поиском, ибо есть индекс. Но когда есть кластерный индекс, то при каждой вставке будет искаться свободная страница для самой таблицы, и если ее нет - она будет расщепляться, ибо кластерный индекс задает упорядочивание самой таблицы.

Дальше Вам надо что-то по кластерному индексу найти. В итоге это уже или скан, что нехорошо, или сик. Второе - это поиск в кластерном индексе (читай - в таблице) по полям этой таблицы, которые уже лежат в неком списке со ссылкой на элементы, которые больше, и на элементы, которые меньше -B-TREE. Так вот и индекс в виде такого дерева хранится, а не в виде мультисета (если, конечно, это обычный индекс, который юзается в 1С, а не gist/hash-индексы, которые в 1С не юзаются).
juker; JohnyDeath; Evil Beaver; sasha777666; +4 Ответить
37. HAMMER_59 206 06.07.17 07:14 Сейчас в теме
(34)
Вот есть у Вас тот мультисет - это просто список с хештаблицей к элементам, полагаю.

Неверно предполагаете, мультисет - это дерево, а дерево это есть частный случай списка.

Структура списка:
- Ссылка на данные
- Следующий элемент

Структура дерева :
- Ссылка на данные
- Левая ветвь
- Правая ветвь

Поэтому я никак не могу вас понять почему в список быстро вставлять, а в дерево (в индекс) долго. Дерево - это частный случай списка.

Не вижу никакой проблемы вставлять элементы в дерево. Вы каждый упоминаете кластерный индекс, но его используют далеко не везде и не всегда.
А я пишу про обычное дерево (обычный индекс), и я не вижу никаких проблем в добавление нового элемента в дерево. Да, каждый раз перед записью будет происходить поиск нужного узла дерева, но это не так долго, для глубины дерева в 20 элементов это уже 1 млн значений, и чем больше глубина тем больше разница, т.е. при глубине дерева 30 элементов это уже 1 млрд. значений.
Да, при количестве элементов в 1 млн, при каждой записи будет осуществлен перебор до 20 элементов (может и с первого раза повезет), но 20 элементов перебрать всяко лучше чем 1 млн.
38. Evil Beaver 6755 06.07.17 09:36 Сейчас в теме
(37) я не совсем понимаю, с чем конкретно вы пытаетесь спорить, и в чем нас убеждаете?
39. HAMMER_59 206 06.07.17 10:57 Сейчас в теме
(38) Так Вы читайте, а не только пишите и станет всё понятно.
Не ленивый, повторю ещё раз.
Почему Вы решили, что запись в индекс происходит долго? Я не вижу никаких оснований, т.к. индекс не что иное как дерево, а дерево это частный случай списка.

Ну и так по мелочи:
Я так и не понял зачем лезть в план запроса.
Во-первых план запроса не является статичным, и для одного и того же запроса меняется в зависимости от ситуации. Я думаю, с этим встречался практически каждый когда один и тот же запрос, в одной и той де базе отрабатывает очень по разному.
Если нужно найти узкое место, зачем лезть в план построения запроса? Можно и без этого получить данные какая часть запроса отрабатывает медленно, и сделать соответствующие выводы.
41. Evil Beaver 6755 06.07.17 13:39 Сейчас в теме
(39)
Можно и без этого получить данные какая часть запроса отрабатывает медленно, и сделать соответствующие выводы.


Поделитесь, пожалуйста, как можно ДОСТОВЕРНО получить сведения о том какая часть запроса отрабатывает медленно, не заглядывая в план запроса. Эмпирически, основываясь на собственном опыте - да можно. Но эта информация будет носить вероятностный характер. План запроса ДОСТОВЕРНО показывает - какая часть запроса работает медленно здесь и сейчас. Вот и вся причина туда заглядывать.
EugeneSemyonov; juker; artbear; +3 Ответить
42. HAMMER_59 206 06.07.17 14:15 Сейчас в теме
(41)
Поделитесь, пожалуйста, как можно ДОСТОВЕРНО получить сведения о том какая часть запроса отрабатывает медленно, не заглядывая в план запроса.

Уже отвечал на этот вопрос - консоль запросов позволяет получить исчерпывающие ответы.
Цитата текста its.1c.ru:

При разработке запросов в конфигураторе, как правило, требуется проводить отладку запроса на реальных данных. Данный инструмент позволяет вести разработку запроса (или пакета запросов) параллельно с просмотром результата. При работе с инструментом в толстом клиенте можно воспользоваться конструктором запросов, как и при работе в конфигураторе. Возможности по анализу результата запроса включают:

вывод данных временных таблиц;
замер времени выполнения запроса и числа строк;
подсветку указанных ячеек в результате запроса;
интерактивное сравнение двух результатов запроса (только в толстом клиенте);
вывод результата запроса в новом окне;
вывод плана выполнения запроса, а также SQL-текст запроса, сформированного в СУБД. Для СУБД Microsoft SQL Server план выполнения выводится в виде дерева, а для остальных СУБД – в текстовом формате технологического журнала. Для упрощения анализа запросов также предусмотрено два режима отображения текстов запросов: с именами таблиц и колонок СУБД или с именами объектов метаданных и реквизитов конфигурации (только в обработке для "1С:Предприятие" версии 8.3).
43. artbear 1184 07.07.17 10:00 Сейчас в теме
(42) Сами себе противоречите :(
(39) - Я так и не понял зачем лезть в план запроса.
Во-первых план запроса не является статичным, и для одного и того же запроса меняется в зависимости от ситуации. Я думаю, с этим встречался практически каждый когда один и тот же запрос, в одной и той де базе отрабатывает очень по разному.
Если нужно найти узкое место, зачем лезть в план построения запроса? Можно и без этого получить данные какая часть запроса отрабатывает медленно, и сделать соответствующие выводы.


(42)
консоль запросов позволяет получить исчерпывающие ответы.
...
вывод плана выполнения запроса, а также SQL-текст запроса, сформированного в СУБД. Для СУБД Microsoft SQL Server план выполнения выводится в виде дерева, а для остальных СУБД – в текстовом формате технологического журнала. Для упрощения анализа запросов также предусмотрено два режима отображения текстов запросов: с именами таблиц и колонок СУБД или с именами объектов метаданных и реквизитов конфигурации (только в обработке для "1С:Предприятие" версии 8.3).
45. HAMMER_59 206 07.07.17 12:43 Сейчас в теме
(43)
Сами себе противоречите :(

В чём Вы видите противоречие?

Я утверждал, что узкое место можно обнаружить и не заглядывая в план запроса. Разве это не так?

Консоль позволяет вывести план запроса, и? С чего вы решили что раз позволяет, значит это крайне ценная информация?

Несерьезно какая-то у Вас тут атмосфера. Показал Вам инструмент, чтобы Вы колесо не изобретали. Сразу все на меня накинулись: "Да как я могу иметь другую точку зрения". У Вас тут что, секта?
46. starik-2005 2177 07.07.17 14:40 Сейчас в теме
(45)
Я утверждал, что узкое место можно обнаружить и не заглядывая в план запроса. Разве это не так?
Не совсем так. Например, в запросе, который вы крутите в консоли запросов, при отборе по высокоселективным данным у Вас может и не быть затыка, если же потом отбор измениться, то селективность другого значения может оказаться иной (низкой) и тот же самый запрос с тем же самым планом запроса, сохраненным в процедурном кеше, выполнится за весьма длительное время.

У меня на практике встречались случаи, когда реально скорость одного и того же запроса могла измениться со временем. Консоль, допустим, покажет, какой конкретно запрос (а подзапрос?) тормозит, но в реальной жизни может оказаться, что этот запрос тормозит только на определенных отборах, а на других работает хорошо. И механизм преодоления таких проблемных ситуаций лежит за пределами консоли запросов - он в профайлере, в планах запросов, в планах обслуживания, в создании нескольких запросов для разных отборов, чтобы планировщик для каждого из них подобрал оптимальный вариант, а не использовал сохраненный в процедурном кеше план.
40. HAMMER_59 206 06.07.17 11:58 Сейчас в теме
(38)
70% статьи написано, про то, что индексы значительно ускоряют поиск.
Я не согласен с самой подачей материала. Для меня индекс - это метод дихотомии, который я могу объяснить очень просто.
Допустим, у Вас нет операции извлечения квадратного корня, напишите функцию нахождения значения.
Допустим, с точностью до 0,001 знака, находим квадратный корень из 150. А дальше все просто если мы используем перебор, нам придется сделать:
12 247 вычислений, прежде чем мы найдем верное значение.
А для метода дихотомии до нужного значения мы дойдем на 19 шаг.

И прямо тут же можно добавить, а вот если бы искали с точность до 1 (т.е. значений было бы всего 150 а не 150 000), получилось бы одинаковое количество вычислений - по 12, и ничего бы мы не выиграли от использования индекса, а только потеряли время на построение индекса.

Оставшаяся часть статьи совсем не понятно про что. СУБД строит план выполнения запроса по неким волшебным алгоритмам, которые нам не подвластны и не понятны.
Я бы сформулировал по-другому. Если вы написали запрос так, что там сам чёрт ногу сломит, не рассчитывайте, что с ним разберётся СУБД, поэтому будьте проще, учитесь писать простые и понятные запросы, если запрос сложный - упрощайте, используйте вложенные таблицы.
59. starik-2005 2177 28.05.19 15:04 Сейчас в теме
(37)
Поэтому я никак не могу вас понять почему в список быстро вставлять, а в дерево (в индекс) долго. Дерево - это частный случай списка.
Да, мультисет - это не просто список, а упорядоченный список, т.е. упорядоченное хранилище кеу->value с прямым и обратным итератором. Вставка и поиск в мультисете - это log2(N), при этом в неупорядоченный список вставить можно за О(1). А для вставки в деревья SQL-базы необходимо записать страницу, в которую вставили данные или индекс, на диск, а т.к. на диск пишется не просто двадцать, допустим, байт индекса, а кластер целиком, то стоимость операции вставки при множестве индексов равна как минимум времени случайной записи такого количества кластеров, которое равно количеству индексов плюс один - сама таблица с данными. При этом если страницы хранения индекса не хватит, то придется на каждый такой индекс и таблицу записать еще по одному кластеру. И если у нас дисковая подсистема допустим выдает 40к IOPS на операциях записи 4к-блоков, то в лучшем случае вставка у на с в индексированную таблицу ограничится этими IOPS деленными на количество индексов + таблица. Из-за этого БД могут эксплуатировать дисковую систему при множественных непоследовательных вставках достаточно сильно, выдавая этакие 1к TPS при записи (тот же pg_bench).
36. Evil Beaver 6755 05.07.17 18:06 Сейчас в теме
(30) проблема вставки в середину списка заключается в поиске середины списка. Мне неизвестно иного способа, кроме сканирования списка.
27. МимохожийОднако 130 05.07.17 08:53 Сейчас в теме
Начало статьи было хорошее. Планируется продолжение? Осталось ощущение недосказанного, оборванного вдруг...
32. DarkUser 05.07.17 13:51 Сейчас в теме
44. herfis 365 07.07.17 10:24 Сейчас в теме
Отличный слог, хорошие статьи. Пишите еще!
Ссылка на вашу "Под капотом управляемых форм" у меня вообще, можно сказать, в буфере обмена. Раздаю направо и налево.
Эта тоже хороша, жалко для меня пользы нет. Ждем продолжения :)
primara; artbear; +2 Ответить
47. JohnyDeath 297 07.07.17 23:14 Сейчас в теме
Неповторимый слог Андрея, повествующих о, казалось бы,замороченных вещах в очень доступной и простой форме.
Ты точно будешь удостоен вторым параллелепипедом!
48. Serg O. 187 08.07.17 00:12 Сейчас в теме
Отлично написано!
Объяснить сложные вещи простым языком - это дано не каждому.

На фразе "тут мы приближаемся к быстродействию тетеньки из регистратуры"
- ржал минут 10, это просто супер!!

Большой респект автору.
juker; корум; primara; jif; JohnyDeath; +5 Ответить
57. juker 222 28.05.19 13:04 Сейчас в теме
(48) Блиц из Зверополиса ))
49. Поручик 4410 02.10.17 11:08 Сейчас в теме
Статью прочитал и понял, что планы запросов как не смотрел никогда, так и не буду, скорей всего, смотреть.

зы Статуэтка от Инфостарта есть.
50. mvxyz 170 02.10.17 23:07 Сейчас в теме
Спасибо за статью! Написано живо и доходчиво. Ждем продолжения.
51. JohnConnor 39 03.10.17 05:02 Сейчас в теме
52. primara 46 04.10.17 10:10 Сейчас в теме
Большое спасибо! Наконец-то нашелся автор, который объяснил наглядно и доходчиво! Даже мне все стало понятно) Очень жду продолжения!
54. ArchLord42 73 06.10.17 05:19 Сейчас в теме
Статья хороша для тех, кто еще не знаком с планами запроса, жалко ее небыло тогда, когда я проходил курсы на эксперта по 1С, потратил бы меньше времени на осознание :)
58. juker 222 28.05.19 13:06 Сейчас в теме
Статья отличная. Давно не читал технических статей написанных таким живым языком.
Спасибо автору.
EugeneSemyonov; +1 Ответить
Оставьте свое сообщение

См. также

[Простые маршруты]. Работа с картой. Геозоны. Расчет оптимальных вариантов доставки Промо

Рабочее место Универсальные обработки Оптовая торговля Оптовая торговля v8 1cv8.cf Оптовая торговля, дистрибуция, логистика УУ Платные (руб)

Универсальное решение для любых конфигураций по отображению на карте адреса доставки из любых документов базы данных. Интерактивная работа с картой из 1С и обратно. Широкий набор средств для формирования маршрутов на карте вручную. Ключевая особенность программы – умение математически точными методами автоматически рассчитать и представить на карте разные варианты оптимальных маршрутов: - исходя из заданного количества единиц автотранспорта; - исходя из заданной величины максимальной грузоподъемности автотранспорта.

10000 руб.

08.02.2016    52079    29    1    

Не спеша, эффективно и правильно – путь разработки. Часть 2. Теория

Практика программирования Бесплатно (free)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

22.06.2020    6453    0    WildHare    23    

Не спеша, эффективно и правильно – путь разработки. Часть 1. Парадигма

Практика программирования Бесплатно (free)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

15.06.2020    9964    0    WildHare    34    

Перенос данных из 1С:Бухгалтерии 7.7 в БП 3.0

Перенос данных из 1С7.7 в 1C8.X Обмен через XML v7.7 v8 1С7:Бух БП3.0 Россия БУ Платные (руб)

Стандартная обработка перехода с 1С:Бухгалтерии 7.7 на 1С:Бухгалтерия предприятия 8, ред.3.0 достаточно сложна в использовании. При ее запуске и попытке выполнения перехода можно встретить большое количество ошибок (примеры ниже). Наша разработка содержит исправление этих ошибок. Также при приобретении нашего переноса данных из 1С:Бухгалтерии 7.7 в БП 3.0 вы получите техническую поддержку наших специалистов по любым вопросам, связанным с этой задачей.

15000 руб.

26.05.2020    1239    0    2    

Перенос данных из КА 1.1 в КА 2 / УТ 11 Промо

Обмен через XML Перенос данных из 1C8 в 1C8 v8 КА1 УТ11 КА2 Платные (руб)

Комплексную автоматизацию для ведения учета обычно выбирают компании среднего и крупного размера, которые не хотят связываться с обменами. При этом в одной программе необходим функционал бухгалтерии, зарплаты и торговли. Комплексная автоматизация 2 решает эту задачу и содержит самые современные разработки фирмы 1С. Программа хорошо отлажена и проверена на учете реальных организаций, потому что разработана на основе проверенных временем УТ 11 и ERP 2. Типовая обработка перехода с Комплексной автоматизации редакции 1.1 на Комплексную автоматизацию редакции 2 не переносит документы. Для переноса документов, начальных остатков и справочной информации можете воспользоваться предлагаемой разработкой (правила конвертации данных из КА 1.1 в КА 2 / УТ 11). При покупке предоставляю поддержку, оперативно исправляю ошибки, рассылаю обновления при выходе новых релизов.

37125 руб.

04.12.2015    134615    356    287    

5 причин 1С-нику участвовать в хакатонах

Личная эффективность Бесплатно (free)

5 причин, зачем вам ходить на хакатоны, почему на это стоит выделять время.

24.05.2020    4609    0    comol    19    

Перенос данных из УНФ 1.6 в БП 3.0

Обмен через XML Перенос данных из 1C8 в 1C8 v8 УНФ БП3.0 Россия БУ УУ Платные (руб)

Обработка для переноса документов, начальных остатков и справочной информации. Можно использовать как для разового начального переноса данных, так и для организации регулярного обмена данными. Есть возможность указать период отбора данных и установить фильтр по организациям. Перенос оперативно обновляем при выходе новых релизов программ 1С. По возникающим вопросам оказываем техническую поддержку (через тикеты на Инфостарте).

15000 руб.

18.05.2020    1400    0    3    

Перенос данных из БП 3.0 в УПП 1.3

Обмен данными 1С Обмен через XML Перенос данных из 1C8 в 1C8 v8 УПП1 БП3.0 Россия Платные (руб)

Поддерживается перенос документов и справочной информации. Есть возможность указать период отбора данных и установить фильтр по организациям. Перенос оперативно обновляем при выходе новых релизов программ 1С. По возникающим вопросам оказываем техническую поддержку (через тикеты на Инфостарте).

15000 руб.

06.05.2020    2126    3    3    

DT:Менеджер 8.2 (8.3) (Распаковка/упаковка *.DT файлов. Быстрый экспорт CF. Сброс пользователей. Работа с "битыми" DT) Промо

Сервисные утилиты Инструментарий разработчика Администрирование данных 1С v8 1cv8.cf Платные (руб)

Внешнее приложение для работы с форматом *.DT. Осуществляет быстрый экспорт конфигурации, очистку сведений о пользователях и может работать с аварийными DT файлами.

6000 руб.

19.04.2013    123874    201    215    

Перенос данных из ERP 2 / КА 2 / УТ 11 в УНФ 1.6

Обмен данными 1С Перенос данных из 1C8 в 1C8 v8 УНФ ERP2 УТ11 КА2 Россия Платные (руб)

Обработка позволяет выполнить полный перенос данных из программ 1С:ERP / КА 2 / УТ 11 в программу 1С:УНФ. Переносятся начальные остатки на выбранную дату, документы за период, а также справочная информация. Переносятся все возможные виды документов. Оказываем техническую поддержку. Оперативно обновляем правила конвертации данных при выходе новых релизов программ 1С.

15000 руб.

28.04.2020    1934    0    6    

Автозагрузка банковских выписок (БП 3.0)

Банковские операции Обмен с банком v8 v8::БУ БП3.0 БУ Абонемент ($m)

Расширение позволяет автоматизировать загрузку банковских выписок в программу 1С:Бухгалтерия предприятия, ред. 3.0. При начальной настройке создается регламентное задание. Период срабатывания регламентного задания в дальнейшем можно поменять в консоли заданий. Требуется указать каталог, из которого нужно загружать банковские выписки.

1 стартмани

06.04.2020    2998    3    primat    5    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    11155    0    informa1555    21    

"Учет и печать ТТН по форме 1-Т и Транспортных накладных" - внешняя печатная форма к документу "Реализация товаров и услуг" для конфигурации "Бухгалтерия предприятия, редакция 3.0" 1С 8.2. Промо

Печатные формы документов Оптовая торговля Производство готовой продукции (работ, услуг) Оптовая торговля Производство готовой продукции (работ, услуг) v8 v8::БУ БП3.0 Россия БУ Платные (руб)

В одной форме вводятся реквизиты для печати двух форм транспортных накладных и сохраняются введенные данные. Обработка подключается к документу "Реализации товаров и услуг", создаются и ведутся дополнительные справочники (транспорт, сведения о грузе, адреса пунктов погрузки). Формируется реестр накладных с необходимым пользователю составом колонок.

1900 руб.

21.10.2013    39827    48    22    

Печать текстовых водяных знаков в файлы PDF из 1С

Универсальные обработки v8 1cv8.cf Абонемент ($m)

Обработка для группового наложения текстовых водяных знаков в документах PDF с помощью бесплатной программы AVS Document Converter. Тестировалась в ОС Windows 7 64 bit на платформе 8.3.15.1830 с AVS Document Converter 4.2.3.268.

2 стартмани

13.03.2020    1060    3    Spartan    8    

Полиграфистки сходят с ума по одной

О жизни Бесплатно (free)

Мой опыт прохождения полиграфа.

06.03.2020    4922    0    1c-intelligence    78    

Перенос документов, остатков и справочников из УНФ 1.6 в УТ 11 / КА 2 / ERP 2 (ЕРП 2)

Обмен данными 1С Обмен через XML Перенос данных из 1C8 в 1C8 v8 УНФ ERP2 УТ11 КА2 Россия Платные (руб)

Правила переноса данных из УНФ в УТ 11 / КА 2 / ERP 2 (ЕРП 2) позволяют перенести начальные остатки на выбранную дату, а также документы за период, начиная с этой даты. Это позволит комфортно начать ведение учета в новой программе 1С. Предоставляем техническую поддержку, оперативно обновляем перенос при выходе новых релизов программ 1С. Добавляем новые виды объектов в переноса по просьбам наших клиентов.

15000 руб.

05.12.2019    5454    5    10    

Заполнение книги учета доходов и расходов (КУДиР) 1С Промо

Обработка документов Налоговые Закрытие периода Закрытие периода Закрытие периода v8 v8::УФ КА1 БП2.0 УПП1 ERP2 БП3.0 КА2 БУ НУ УСН Платные (руб)

При формировании КУДиР при УСН часто возникает множество вопросов и проблем, к.т.: 1. Как выполняется заполнение книги учета доходов и расходов 2. Неправильно формируется книга учета доходов и расходов в 1С а). Доходы / расходы не попадают в КУДиР; б). Доходы / расходы попадают, но не принимаются к учету и многие другие ошибки. При правильном учёте, книга формируется корректно, но идеальный учет это скорее фантастика, для реальных случаев можно использовать специальный инструмент. Обработка предназначена для просмотра и заполнения КУДиР. Заполнение может производиться как штатным, так и альтернативным способом (от бухгалтерской проводки).

4900 руб.

12.03.2014    105533    58    81    

Универсальное выборочное удаление данных из базы 1С (любые конфигурации на упр.формах: БП 3.0, УТ 11, КА 2, ERP, УНФ, ЗУП 3, Розница и т.д.)

Чистка базы Универсальные обработки v8 v8::УФ Розница УНФ ERP2 ЗКГУ3.0 БП3.0 УТ11 КА2 ЗУП3.x Платные (руб)

Обработка позволяет удобно выборочно удалить данные из базы 1С. Это могут быть как неиспользуемые элементы справочников, так и неактуальные организации. При этом есть возможность провести анализ пересечений документов с другими организациями и таким образом уберечься от того, что при удалении обороты по другой организации изменятся.

3000 руб.

28.11.2019    4189    10    7    

Стабильность превыше всего

Рефакторинг и качество кода v8 Бесплатно (free)

Странная заметка о поддержании стабильности в условиях интенсивного изменения конфигурации.

07.11.2019    9033    0    YPermitin    40    

6 шотов

О жизни Бесплатно (free)

Небольшие пятничные истории о взаимоотношениях в коллективе

01.11.2019    9678    0    sapervodichka    28    

Загрузка документов в 1С (7.7) из табличных файлов Excel,OpenOffice,1C,DBF,TXT (обработка) Промо

Файловые протоколы обмена, FTP Загрузка и выгрузка в Excel 1С7.7<->1C7.7 v7.7 1cv7.md Платные (руб)

Обработка решает поставленную задачу по вводу документов, а кроме того обладает важной функцией: настраивается на ассортимент конкретного поставщика, запоминая соответствие между его номенклатурой и «нашей». Т.е. фактически – является самообучающейся системой ввода накладных. У разных поставщиков могут быть накладные различного типа, с разным количеством полей, поэтому для каждого из них может быть сохранена своя собственная настройка диалоговой формы так, что любая поступающая накладная может быть обработана. По отношению к программе "1С:Предприятие 7.7" данное решение является внешними файлами. Для использования данного продукта не требуется вносить изменения в алгоритм существующих программ или используемых конфигураций.

1500 руб.

10.12.2009    63066    50    93    

Шорты Белокаменцева

О жизни Бесплатно (free)

Короткие версии старых статей

28.10.2019    7718    0    1c-intelligence    18    

Перенос данных из КА 1.1 / УПП 1.3 / УТ 10.3 в УНФ 1.6

Обмен данными 1С Перенос данных из 1C8 в 1C8 v8 КА1 УПП1 УНФ Россия Платные (руб)

Перенос остатков, документов и справочников из КА 1.1 / УПП 1.3 / УТ 10.3 в УНФ 1.6. Обработка позволяет начать учет в программе "1С:Управление нашей фирмой" - перенести в нее из существующей базы "1С:Управление производственным предприятием 1.3" / "1С:Комплексная автоматизация 1.1" начальные остатки на выбранную дату, документы за период времени и также всю необходимую справочную информацию. По вашему запросу бесплатно добавляю в перенос дополнительные виды объектов (например, новые виды документов). Перенос включает в себя правила конвертации в формате XML, обработку для выгрузки и загрузки данных, а также инструкцию по работе. В стоимость переноса включена техподдержка в течение месяца с момента покупки, а также получение обновлений переноса в течение полугода.

15000 руб.

17.10.2019    6765    6    12    

Перенос данных из Управление торговлей 10.3 в Бухгалтерию предприятия 3.0 (правила переноса остатков, документов и справочников из УТ 10.3 в БП 3.0)

Обмен через XML Перенос данных из 1C8 в 1C8 v8 УТ10 БП3.0 Россия БУ УУ Платные (руб)

Правила переноса остатков, документов и справочников из УТ 10.в БП 3.0 позволяют как начать вести учет в новой базе БП 3.0, так и организовать регулярный обмен данными, вводимыми на стороне УТ 10.3. Перенос оперативно обновляем на новый релизы, предоставляем техническую поддержку. Возможно бесплатное выполнение тестового переноса данных перед приобретением нашей разработки.

10000 руб.

02.10.2019    5429    2    9    

Алкогольная декларация для 1С 8.1, 8.2, 8.3 (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 формы) УТ10.2/10.3, УТ11, УПП, КА, БП2.0/3.0, БП КОРП, Розница 1.0/2.1, Далион, Астор, УТАП и др. с подписью и шифрованием, редакция 2.3 Промо

Регламентированная отчетность Бухгалтерские Налоговые Розничная торговля Розничная торговля v8 КА1 БП2.0 Розница УПП1 БП3.0 УТ11 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Рестораны, кафе и фаст-фуд Пищевая промышленность Россия БУ НУ Акцизы Платные (руб)

Сложности с подготовкой алкогольной декларации? Срок сдачи все ближе, а Вы не успеваете? Устали заносить/править данные вручную? Давит угроза штрафа в десятки тысяч или лишение лицензии? Бессонные ночи и потраченные на работе вечера в пик сдачи отчетности? Надоело формировать отчет для каждого клиента и отсылать вручную? Вам знакомы эти проблемы? Если да, то у нас есть РЕШЕНИЕ, которое Вам поможет! Автоматическое и ручное заполнение алкогольных деклараций по формам 1, 3 (производство), 2, 4 (использование), 5, 6, 7 (опт), 8, 9 (перевозка), 10 (использование мощностей), 11, 12 (розница, разделы I и II) по данным учета, проверка и шифрование, а также загрузка из внешних файлов и выгрузка в последнем актуальном формате 4.31.

20000 руб.

23.10.2012    209968    285    414    

Видя деньги

О жизни Бесплатно (free)

Немножко бизнес-программирования.

09.09.2019    8194    0    1c-intelligence    94    

Куда и как расти

Личная эффективность Бесплатно (free)

Даже если сейчас у вас стабильная работа, это не означает, что завтра ситуация не изменится, вы не окажетесь на рынке труда в поисках новой должности. Какие специалисты сейчас требуются, и какие тренды превалируют на рынке IT и в сфере 1С, на конференции рассказал директор по развитию внедренческого центра «Раздолье» Андрей Мироненко. Он работает в качестве руководителя IT-направления свыше 15 лет, а в должности директора IT – 10 лет. Является автором различных обзоров, курсов и иных полезных материалов. Занимался подбором и мотивацией персонала, разработкой стандартов качества IT-сервисов, руководством проектами автоматизации (ERP, WMS и пр), имеет опыт организации розничных сетей, call-центров, запуска и сопровождения интернет-магазинов.

16.05.2019    11607    0    andironenko    26    

Универсальный HTTP-сервис на платформе 1С, аля HTTP-сервер с примером

Инструментарий разработчика v8 1cv8.cf Абонемент ($m)

Практический кейс построения HTTP-сервиса, который работает по принципу HTTP-сервера, с разбором всех методов построения и разработки класса задач построения личных кабинетов и сопряжения их с центральной базой.

1 стартмани

13.05.2019    26718    119    Diversus    42    

Удаленная работа. Как выбрать работодателя

Личная эффективность Бесплатно (free)

На что обратить внимание при выборе удаленного работодателя

15.11.2018    11649    0    sergey_garin    24    

В гости к отцу

О жизни Бесплатно (free)

Про старых и новых инженеров.

14.11.2018    7380    0    1c-intelligence    34    

Контроль отрицательных остатков в конфигурациях: УТ 11.4, КА 2.4, ЕРП 2.4

Бухгалтерский учет Учет ТМЦ Управленческий учет (прочее) Учет ТМЦ v8 v8::УФ ERP2 УТ11 КА2 Россия УУ Бесплатно (free)

Подробный разбор всех присутствующих в конфигурациях УТ 11, КА 2, ЕРП 2 вариантов контроля отрицательных остатков: по организациям, складам, оперативный контроль

08.11.2018    50210    0    ids79    73    

Обмен каталогом товаров между 1С и другими системами в формате YML (Yandex Market Language) Промо

Обмен через XML WEB Оптовая торговля Розничная торговля Оптовая торговля Розничная торговля v8 УТ10 УНФ УТ11 Платные (руб)

Обработка для выгрузки/загрузки каталога номенклатуры в 1С из формата YML (Yandex Market Format). В настоящий момент поддерживается выгрузка в YML из УТ11 и УТ10. Загрузки из YML в УТ11, УТ10 и УНФ 1.6. Обработки тестировалась на конфигурациях УТ 11.3.1.115 (управляемые формы), УНФ 1.6.9.36 (управляемые формы) и УТ 10.3.32.2 (обычные формы). Обращайтесь по вопросом адаптации обработки под другие конфигурации. Обработка предоставляется с открытым кодом. Кроме того, будет осуществляться развитие проекта. Выпускаемые обновления будут распространяться среди покупателей БЕСПЛАТНО в течение 1 года с момента покупки. Обратите внимание, что при чтении YML-файлов большого размера может происходить увеличение размера временных файлов 1С. Поэтому для быстрого чтения объемных файлов необходимо иметь соответствующей мощности ПК. Если есть потребность быстро загружать объемные файл рекомендуется использовать сервера, а не обычные ПК.

4900 руб.

18.05.2015    64060    110    48    

О главном инструменте разработчика, аналитика и руководителя

Личная эффективность Бесплатно (free)

Думаю, все были на собеседованиях и на вопрос «какие инструменты вы используете в работе», у всех заготовлен ответ про языки, библиотеки, среды разработки, базы данных и т.д. и т.п. В крайнем случае, у кого-то может быть припасена шутка про грабли и напильник. Ну и все доблестно перечисляют всякие XDTO и СКД, думая, что перечисляют невероятно важные средства разработки, в которых хорошо разбираются. Но правда заключается в том, что единственно важным средством разработки является ваш мозг. И вы абсолютно ничего не знаете о том, как он устроен.

10.08.2018    10772    0    m-rv    40    

Способы оптимизации переносов данных

Перенос данных из 1C8 в 1C8 Интеграция v8 КД Абонемент ($m)

Хочу рассказать вам про способы оптимизации разработки правил обмена в программе «Конвертация данных» второй редакции. Казалось бы, про эту программу и разработку в ней правил конвертации уже сказано все, что можно. Появились уже более современные и быстрые технологии. Почему же все еще она? Дело в том, что «Конвертация данных» второй редакции все еще актуальна для огромного круга задач. Она имеет очень широкую функциональность и позволяет реализовывать сложные алгоритмы. Годы идут, а люди продолжают ей пользоваться и у них возникает много вопросов по этой программе. Возможно, в будущем вы тоже будете заниматься такими проектами и столкнетесь с задачами, похожими на те, про которые я собираюсь рассказать. Мне хочется вам в этом помочь.

1 стартмани

02.08.2018    16510    11    primat    7    

Минимализмы 3

Практика программирования Универсальные функции v8 Бесплатно (free)

Очередная серия "минимализмов" [http://infostart.ru/public/306536/, https://infostart.ru/public/460935/]. Также, как и в предыдущих статьях, здесь приведена подборка коротких оригинальных авторских решений некоторых задач. Ранее эти решения были разбросаны по моим комментариям к чужим публикациям.

19.02.2018    44929    0    ildarovich    45    

Распознавание документов в "1С:Предприятие 8.3": расширение для типовых конфигураций. Промо

Обработка справочников Внешние источники данных Управление персоналом (HRM) Управление персоналом (HRM) v8 1cv8.cf Платные (руб)

Расширение для типовых конфигурация и для самостоятельной интеграции системы распознавания документо удостоверяющих личность и прочих документов непосредственно из информационных баз "1С:Предприятия 8.3". Расширение позволит не изменять типовой код конфигурации, расширить текущий функционал несколькими кликами мыши.

5000 руб.

26.01.2016    47950    62    0    

А чё это вы здесь делаете, а?

WEB v8 1cv8.cf Абонемент ($m)

Разработчикам тиражных обработок близка и понятна проблема обратной связи с пользователем. Много важного и полезного можно почерпнуть, зная, что делает бухгалтер, который запустил обработку. В большом мире вэба сбор статистики на сайте дело привычное и даже обязательное. Эта статья покажет практику применения инструментов сбора статистики из мира веба для обработок на платформе 1С:Предприятие.

1 стартмани

21.01.2018    22986    31    infosoft-v    42    

Одно Кольцо, Чтобы Править Всеми

Личная эффективность Бесплатно (free)

Рассказ о внедрении 1С. Необычный.

25.12.2017    15036    0    1c-intelligence    62    

Джеб Кличко

Личная эффективность Бесплатно (free)

Бывает же такое: 1Сник может учиться у Кличко

18.12.2017    16313    0    1c-intelligence    63    

Латентные паразиты

Управление бизнес-процессами (BPM) Бесплатно (free)

Вот вы сидите, и не думаете о паразитах. А они рядом.

04.12.2017    25850    0    1c-intelligence    144    

Комплект увольнения

О жизни Бесплатно (free)

Это все, что останется после меня. Это все, что возьму я с собой.

28.11.2017    26861    0    1c-intelligence    87    

Суррогаты

О жизни Бесплатно (free)

Статья о том, что вы и без меня прекрасно знаете. Но я напомню.

21.11.2017    28785    0    1c-intelligence    197    

Простой способ повысить шансы на победу, переговоры без поражения. Тонкое искусство переговоров для специалистов по 1С и не только. Часть 2

Личная эффективность Бесплатно (free)

После своей предыдущей публикации https://infostart.ru/public/690718/ получил много сообщений с вопросами. Один из наиболее часто повторяющихся – о том, как повысить шансы на победу в сложных переговорах, если этому никогда не учился? Конечно, от это вопроса веет верой в Гарри Поттера и его волшебную палочку, но мы точно знаем, что правильный ответ есть. Используйте принцип «всегда вдвоем». Это одна из самых простых и самых сильных манипуляций в переговорах.

07.11.2017    10297    0    user809424    17    

Кошка сдохла, хвост облез

Личная эффективность Бесплатно (free)

Практический прием для руководителя из арсенала системного мышления.

04.11.2017    17612    0    1c-intelligence    44    

Экзорцизм программистскими методами

О жизни Бесплатно (free)

Примеры из жизни о том, как инструменты на платформе 1С помогают компании изгонять зло.

24.08.2017    33675    0    1c-intelligence    59    

Рассылка СМС-сообщений через сервис SMS.ru

SMS рассылки v8 1cv8.cf Россия Абонемент ($m)

Простая конфигурация, позволяющая быстро организовать смс-рассылку через интернет-сервис SMS.ru. Конфигурация собрана на платформе 1С:Предприятие 8.3 (8.3.8.2088), механизм взаимодействия с внешним сервисом - http запросы.

1 стартмани

20.08.2017    11493    43    sdn-1    0    

Агрессия в переговорах

Личная эффективность Бесплатно (free)

Многие люди сравнивают агрессию с отсутствием такта и невоспитанностью либо с плохим настроением. И мало кто задумывается, что она может стать помощником, особенно когда идет речь о сотрудничестве или переговорах с партнерами. Чем может быть полезна агрессия и как правильно ею пользоваться, рассказывает бизнес-тренер, руководитель Петербургской школы переговорщиков «ШИП» Дмитрий Коткин.

08.08.2017    12321    0    user809424    45    

Умный дом на 1С + ардуино

Практика программирования v8 Абонемент ($m)

Конфигурация для автоматизации быта программиста 1C и не только. В данной статье будет рассказано, как можно использовать 1С для задач, не входящих в стандартные рамки этой платформы. Например, управление домом. В качестве периферии для подключения будет использован микроконтроллер (МК) Ардуино, но на нём не будет никакой логической нагрузки, весь процесс будет проходить на сервере 1С. Работа с пинами ввода/вывода происходит напрямую из 1С.

1 стартмани

07.08.2017    20958    20    sasha777666    63    

Как я стал одинэсником и переехал из провинции в Москву

О жизни Россия Бесплатно (free)

История покорения Москвы.

29.07.2017    16838    0    DmitryKSL    132