Size: a a a

PostgreSQL + 1C + Linux

2020 June 30

11

19 17 in PostgreSQL + 1C + Linux
во внешней КИС есть код номенклатуры.
для документа по нему надо найти элемент справочника
источник

11

19 17 in PostgreSQL + 1C + Linux
делать в цикле "НайтиПоКоду" - неправильно
источник

11

19 17 in PostgreSQL + 1C + Linux
в обычном запросе сделать джойн внешней таблицы и справочника товаров не получится
источник

2_

2flower _ in PostgreSQL + 1C + Linux
19 17
делать в цикле "НайтиПоКоду" - неправильно
этот же код в 1С. а почему не правильно?
источник

2_

2flower _ in PostgreSQL + 1C + Linux
в 7-ке я такое делал работает быстро даже на 5-7к записей.
источник

11

19 17 in PostgreSQL + 1C + Linux
потому что каждое выполнение это отдельный запрос к базе.
источник

11

19 17 in PostgreSQL + 1C + Linux
в крайнем случае - прочитать данные из справочника запросом, закинуть в таблицузнацений, проиндекстировать и там искать.
источник

2_

2flower _ in PostgreSQL + 1C + Linux
19 17
потому что каждое выполнение это отдельный запрос к базе.
я не скажу за 1с как там внутри на 100 мелких запросов по ПК в БД-дают небольшие накладные расходы,
чем сама 1с.
источник

2_

2flower _ in PostgreSQL + 1C + Linux
у меня есть правило, не выделываться, все что можно выбрать в бд делать там,
т.к. уровень создателей бд выше, чем мой, возможно в связке с 1с это работать не будет,
время покажет.
источник

11

19 17 in PostgreSQL + 1C + Linux
1000 вызовов найти по коду приведут к 1000 запросам к бд, составлению плана запросов и.т.д.
кроме того что это будет медленнее чем выбрать один раз, это будет занимать ресурсы сервера.
источник

11

19 17 in PostgreSQL + 1C + Linux
источник

11

19 17 in PostgreSQL + 1C + Linux
простейший пример
источник

11

19 17 in PostgreSQL + 1C + Linux
как сделать быстро и эффективно без говнокода.
источник

2_

2flower _ in PostgreSQL + 1C + Linux
19 17
1000 вызовов найти по коду приведут к 1000 запросам к бд, составлению плана запросов и.т.д.
кроме того что это будет медленнее чем выбрать один раз, это будет занимать ресурсы сервера.
я не буду с вами спорить, у меня не та компетенция в 1с, ваши 1000 запросов в PREPARE и просто запросы, это как говорят в Одессе две большие разницы.

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

11

19 17 in PostgreSQL + 1C + Linux
PREPARE это создание параметрического запроса?
источник

2_

2flower _ in PostgreSQL + 1C + Linux
19 17
PREPARE это создание параметрического запроса?
prepare -это подготовленный запрос, вы учите бд, он делает план ОДИН раз, ОДИН раз парсит, накладных расходов нет.
источник

11

19 17 in PostgreSQL + 1C + Linux
я это и имел ввиду
источник

2_

2flower _ in PostgreSQL + 1C + Linux
параметрический запрос и prepare -это разное
источник

2_

2flower _ in PostgreSQL + 1C + Linux
чтобы не выдумывать.
PREPARE создаёт подготовленный оператор. Подготовленный оператор представляет собой объект на стороне сервера, позволяющий оптимизировать производительность приложений. Когда выполняется PREPARE, указанный оператор разбирается, анализируется и переписывается. При последующем выполнении команды EXECUTE подготовленный оператор планируется и исполняется. Такое разделение труда исключает повторный разбор запроса, при этом позволяет выбрать наилучший план выполнения в зависимости от определённых значений параметров.
Подготовленные операторы потенциально дают наибольший выигрыш в производительности, когда в одном сеансе выполняется большое число однотипных операторов.
источник

2_

2flower _ in PostgreSQL + 1C + Linux
а это что?
источник