|
|
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Имеем конфигурацию 1С:Предприятие 8.3 (8.3.5.1248) Используем для работы PostgreSQL 9.2 (взятую с сайта 1С) на сервере под CentOS 6.6 x86_64. Выполняется ресурсоемкий запрос запрос.Текст = "ВЫБРАТЬ | Организации.Ссылка КАК Организация, | СУММА(ЕСТЬNULL(ХозрасчетныйОстатки01.СуммаОстаток, 0)) КАК СуммаОстаток01, | ЕСТЬNULL(ХозрасчетныйОстатки0810.СуммаОстаток, 0) КАК СуммаОстаток0810, | ЕСТЬNULL(ХозрасчетныйОстатки41.СуммаОстаток, 0) КАК СуммаОстаток41, | ЕСТЬNULL(ХозрасчетныйОстатки51.СуммаОстаток, 0) КАК СуммаОстаток51, | ЕСТЬNULL(ХозрасчетныйОстатки51а.СуммаОстаток, 0) КАК СуммаОстаток51а, | ЕСТЬNULL(ХозрасчетныйОстатки50.СуммаОстаток, 0) КАК СуммаОстаток50, | ЕСТЬNULL(ХозрасчетныйОстатки51б.СуммаОстаток, 0) КАК СуммаОстаток51б |ИЗ | Справочник.Организации КАК Организации | ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ОсновныеСредства)), , ) КАК ХозрасчетныйОстатки01 | ПО Организации.Ссылка = ХозрасчетныйОстатки01.Организация | ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки( | КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), | Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ВложенияВоВнеоборотныеАктивы)) | ИЛИ Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.Материалы)), | , | ) КАК ХозрасчетныйОстатки0810 | ПО Организации.Ссылка = ХозрасчетныйОстатки0810.Организация | ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.Товары)), , ) КАК ХозрасчетныйОстатки41 | ПО Организации.Ссылка = ХозрасчетныйОстатки41.Организация | ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.РасчетныеСчета)), , Субконто1.банк.код = ""xxx"") КАК ХозрасчетныйОстатки51 | ПО Организации.Ссылка = ХозрасчетныйОстатки51.Организация | ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.РасчетныеСчета)), , Субконто1.банк.код = ""xxx"") КАК ХозрасчетныйОстатки51а | ПО Организации.Ссылка = ХозрасчетныйОстатки51а.Организация | ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.Касса)), , ) КАК ХозрасчетныйОстатки50 | ПО Организации.Ссылка = ХозрасчетныйОстатки50.Организация | ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.РасчетныеСчета)), , Субконто1.банк.код = ""ххх"") КАК ХозрасчетныйОстатки51б | ПО Организации.Ссылка = ХозрасчетныйОстатки51б.Организация |ГДЕ | Организации.ИНН <> ""ххх"" | |СГРУППИРОВАТЬ ПО | Организации.Ссылка, | ЕСТЬNULL(ХозрасчетныйОстатки0810.СуммаОстаток, 0), | ЕСТЬNULL(ХозрасчетныйОстатки41.СуммаОстаток, 0), | ЕСТЬNULL(ХозрасчетныйОстатки51.СуммаОстаток, 0), | ЕСТЬNULL(ХозрасчетныйОстатки51а.СуммаОстаток, 0), | ЕСТЬNULL(ХозрасчетныйОстатки50.СуммаОстаток, 0), | ЕСТЬNULL(ХозрасчетныйОстатки51б.СуммаОстаток, 0) | |УПОРЯДОЧИТЬ ПО | Организации.Наименование"; База данных весит около 1.2 ГБ, во время выполнения запроса в оперативной памяти занимает 10 ГБ. Данные примерно за 2 года. Понимаю, что запрос не оптимальный, но программисты наотрез отказываются его менять ссылаясь на то, что на MSSQL он работает. авторВ результате выполнения 1С выдает ошибку Невосстановимая ошибка Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: по причине: Ошибка СУБД: ERROR: too many range table entries Попытка разобраться с помошью гугла к успеху не привела. Единственное, что я обнаружил это комментарий в исходном коде PostgreSQL автор/* * Check for RT index overflow; it's very unlikely, but if it did happen, * the executor would get confused by varnos that match the special varno * values. */ if (IS_SPECIAL_VARNO(list_length(glob->finalrtable))) ereport(ERROR, (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED), errmsg("too many range table entries"))); Хотелось бы понять из-за чего возникает такая проблема и как ее можно устранить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 12:41:21 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
argenon, перейдите на мсскл или увольте кодеров 1-е -- проще 2-е -- чревато необходимостью много что переписывать в 1С, за 1С, поперёк 1С а ошибка -- это 1С -- "но ведь других нет"(СС) так что переходите на мсскл и не парьте мозги спойлер Код: c Код: c ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 14:41:09 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
спойлер, тут уже дело принципа - понять что происходит. Поясните, пожалуйста, про INNER_VAR ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 14:54:21 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
argenonспойлер, тут уже дело принципа - понять что происходит. Поясните, пожалуйста, про INNER_VAR Для начала посмотрите в какой SQL запрос преобразуется вышеприведенный птичий язык... это раз (перевести с птичьего языка на нормальный SQL не всегда просто)... два - посмотрите нет ли там партиционирования в тех или иных таблицах учатсвующих в запросе. По логике эта ошибка может только при партиционировании возникать. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 15:28:49 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, SQL запрос у меня есть в логе posqtgresql, но не знаю, как бы обезличить данные. Если только очистить таблицы. Про партиционирование 1с-прораммисты не слышали. В конфиге postgresql установлено значение constraint_exclusion = partition ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 15:54:06 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukargenonспойлер, тут уже дело принципа - понять что происходит. Поясните, пожалуйста, про INNER_VAR Для начала посмотрите в какой SQL запро с преобразуется вышеприведенный птичий язык... это раз (перевести с птичьего языка на нормальный SQL не всегда просто)... два - посмотрите нет ли там партиционирования в тех или иных таблицах учатсвующих в запросе. По логике эта ошибка может только при партиционировании возникать. --Maxim Boguk <> поскольку там Код: sql 1. то это может быть отнюдь не "один "SQL запрос", а как минимум свёртка с времянками. (1С любит некоторые выборки COPY FROM STDOUT во времяночки, а потом чутка с ними возиться) или даже наброс кучи подвыборок "вдоль иерерахий" в такие времянки, с последующей сверткой. (эта конструкция и способы её реализации в 1С появились задолго до появлений в субд-ах кляузы "with recursive", и вряд ли её, т.е. коснтрукции, реализацию с тех пор переписывали , тем паче -- субд -зависимым способом ) т.е. в этом случае имеет место быть не простая "трансляция", а трансляция с изподвывертом. да и тип свёртки -- full join -- не подарок Опять же , шняги типа Код: sql 1. 2. 3. 4. -- это не таблицы, а некоторые, скорее всего организованные через те же времянки "параметрические" выборки [из таблиц остатков -- сиречь "регистров"]. (могли бы быть хранимками, но это не 1С-вэй). ps 2тс: а что пояснять -- есть некая тупая константа -- 65000. вы за неё выкатились. с чем вас и поздравляем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 17:08:04 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
argenon, Пожалуйста, "не грузите" местных, а лучше дайте почитать вашим 1С разработчикам 1) http://its.1c.ru/db/metod8dev#content:1556:hdoc "Использование конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN (ERROR: "FULL JOIN is only supported with mergejoinable join conditions"). Для реализации полной поддержки FULL OUTER JOIN при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ снижается. В связи с этим не рекомендуется использовать ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ при работе с PostgreSQL. В большинстве случаев без использования этой конструкции можно обойтись, переписав исходный запрос." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 20:08:47 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
argenon, а потом пусть читают до просветления http://kb.1c.ru/articleView.jsp?id=44 (Типичные причины неоптимальной работы запросов и методы оптимизации) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 20:11:11 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
argenon, На мой взгляд запрос не действительно не оптимальный, т.к. виртуальные таблицы остатков преобразуются в подзапросы, а соединение подзапросов может поставить в тупик оптимизатор (заставит сгенерировать неоптимальный план). Можно запрос переписать с использованием временных таблиц. Да, и действительно, не рекомендуют использовать FULL OUTER JOIN на Postgres. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 20:59:18 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Спасибо за советы. Выложу SQL запрос, который формирует 1с. Запрос оказался не маленьким поэтому только в виде архива. https://yadi.sk/d/ujT5Z4brd49yn Может кому-то будет интересно взглянуть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 21:38:56 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
argenonСпасибо за советы. Выложу SQL запрос, который формирует 1с. Запрос оказался не маленьким поэтому только в виде архива. https://yadi.sk/d/ujT5Z4brd49yn Может кому-то будет интересно взглянуть. Запрос на 28MB? Вы смеетесь? Не удивительно что оно не работает. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 22:11:08 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
argenonСпасибо за советы. Выложу SQL запрос, который формирует 1с. Запрос оказался не маленьким поэтому только в виде архива. https://yadi.sk/d/ujT5Z4brd49yn Может кому-то будет интересно взглянуть. чотаржу спасибо, давненько я отвык от рассматриваний работы 1С поделий изнутре. доставляет. таки они всю иерархию через union ALL-ы и преднаборы {IN (SELECT ..) OR IN(SELECT ...)} -ов от {_ref-ов} собирают ночнче (но не времянки, как я полагал). Ше ,таки, девр (!) ящетаю. 30 мб sql-я -- это не конь чихнул. вашим кодерам надо научится "1С-sql" писать правильно, а не в стиле 1С -- "всё в кучку, а потом весь хлам сворачиваем, заметая крошки под ковёр". Сначала все свертываем по требуемым измерениям ВНУТРИ отдельных таблиц отстатков(добивая 0 отсутствующие в данной табле ), потом результаты или джойним (если не добивали), или (если добивали отсутствующее нолями) -- union-all-аем (как делает унтре сам 1С). и только потом -- крепим "снаружи" (после состоявшейся свёртки) к готовым сверткам справочники -- расшифровки. тогда 1с-движку не придется так извращаться, перебирая все возможные, но не реализуемые данными варианты "FULL JOIN"-ов ну вот тут ваши коллеги понабежали, уже с опытом и ссылками -- внемлите, оно полезно, да и на вашем же птичьем жаргоне люди изъясняются -- т.ч. разберётесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 22:32:03 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
laskin82argenon, Пожалуйста, "не грузите" местных, а лучше дайте почитать вашим 1С разработчикам 1) http://its.1c.ru/db/metod8dev#content:1556:hdoc "Использование конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN (ERROR: "FULL JOIN is only supported with mergejoinable join conditions"). Для реализации полной поддержки FULL OUTER JOIN при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ снижается. В связи с этим не рекомендуется использовать ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ при работе с PostgreSQL. В большинстве случаев без использования этой конструкции можно обойтись, переписав исходный запрос." Они обкурились? FULL JOIN отлично эмулируется UNION'ом, оверхед на практике в среднем процентов 15. Интересно, а в своих конфах они ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ используют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 09:28:06 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Что касается темы, то уверен, что при трансляции 1с делает много внутренних запросов, а у postgresql predicate pushdown отсутствует как класс. И вряд ли 1совцы писали свой, там для этого тучу чего надо. Так что либо крестик снимите либо трусы наденьте. То есть либо уходите с PostgreSQL, либо уходите с 1С. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 09:30:13 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
argenonСпасибо за советы. Выложу SQL запрос, который формирует 1с. Запрос оказался не маленьким поэтому только в виде архива. https://yadi.sk/d/ujT5Z4brd49yn Может кому-то будет интересно взглянуть. Кстати удивительно что оно вообще работает. Потому лично наблюдал как при запросах >5 мб postgresql с очень большой вероятностью падал, причем вместе с операционкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 09:34:36 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
спойлерСначала все свертываем по требуемым измерениям ВНУТРИ отдельных таблиц отстатков(добивая 0 отсутствующие в данной табле ), потом результаты или джойним (если не добивали), или (если добивали отсутствующее нолями) -- union-all-аем (как делает унтре сам 1С). и только потом -- крепим "снаружи" (после состоявшейся свёртки) к готовым сверткам справочники -- расшифровки. Замечательный совет. Может им сразу готовый план давать postgre, че уж там? (жалко у него только хинтов нет) Переходите на MS SQL короче и не дурите людям голову. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 09:39:13 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
спойлертаки они всю иерархию через union ALL-ы и преднаборы {IN (SELECT ..) OR IN(SELECT ...)} -ов от {_ref-ов} собирают ночнче (но не времянки, как я полагал). Это как? Что не догоняю как оператор примитивной рекурсии можно без императивщины (то есть table functions и while'а внутри) реализовать? А что касается RECURSIVE CTE, то там столько ограничений, что кроме примитивных случаев его особо и не используешь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 09:43:13 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Nitro_Junkielaskin82argenon, Пожалуйста, "не грузите" местных, а лучше дайте почитать вашим 1С разработчикам 1) http://its.1c.ru/db/metod8dev#content:1556:hdoc "Использование конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN (ERROR: "FULL JOIN is only supported with mergejoinable join conditions"). Для реализации полной поддержки FULL OUTER JOIN при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ снижается. В связи с этим не рекомендуется использовать ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ при работе с PostgreSQL. В большинстве случаев без использования этой конструкции можно обойтись, переписав исходный запрос." Они обкурились? FULL JOIN отлично эмулируется UNION'ом, оверхед на практике в среднем процентов 15. Интересно, а в своих конфах они ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ используют. есть одна проблема - 1 full join это 2 Запроса в union 2 full join - 4 запроса в union (если без CTE) 3 full join - 8 запросов и тд в исходном запросе у нас толи 7 толи 8 FULL JOIN как я понимаю отсюда и проблемы с длинной запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 09:47:51 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Maxim BogukNitro_Junkieпропущено... Они обкурились? FULL JOIN отлично эмулируется UNION'ом, оверхед на практике в среднем процентов 15. Интересно, а в своих конфах они ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ используют. есть одна проблема - 1 full join это 2 Запроса в union 2 full join - 4 запроса в union (если без CTE) 3 full join - 8 запросов и тд в исходном запросе у нас толи 7 толи 8 FULL JOIN как я понимаю отсюда и проблемы с длинной запроса. Это почему 2 FULL JOIN - 4 запроса ? SELECT COALESCE(A.id, B.id, C.id) A FULL JOIN B ON A.id = B.id FULL JOIN C ON C.id = COALESCE(A.id, B.id) разве не эквивалентно : (SELECT A.id FROM A) UNION (SELECT B.id FROM B) UNION (SELECT C.id FROM C). Да если нужно другие поля тянуть, придется в каждом подзапросе LEFT JOIN остальных делать, но запроса то 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 09:59:23 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Nitro_Junkieспойлертаки они всю иерархию через union ALL-ы и преднаборы {IN (SELECT ..) OR IN(SELECT ...)} -ов от {_ref-ов} собирают ночнче (но не времянки, как я полагал). Это как? Что не догоняю как оператор примитивной рекурсии можно без императивщины (то есть table functions и while'а внутри) реализовать? А что касается RECURSIVE CTE, то там столько ограничений, что кроме примитивных случаев его особо и не используешь... да примитивно, ДО выполнения запроса они обходят клиентом в цыклах все "иерархии" и составляют наборы условий для каждого уровня. А потом Джойнят Все узлы одной иерархии на все узлы другой -- а результат UNION -ALL -ят. Т.е. императивно (в DO-while-ах) они пошивают те самые 30 мб сверток перестановками. если открыть их детище -- мы увидим, что сначала джойнятся выборки с условием Код: sql 1. 2. 3. 4. 5. -- это 4 корня какой- то одной иерархии , наверное : Код: sql 1. Потом -- к ним добавляется Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. -- это скорее всего получено из Код: sql 1. 2. -- вопрос, где они набрали то дикое количество перестановок (комбинаторику) мне пока не ясен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 11:38:41 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
спойлерNitro_Junkieпропущено... Это как? Что не догоняю как оператор примитивной рекурсии можно без императивщины (то есть table functions и while'а внутри) реализовать? А что касается RECURSIVE CTE, то там столько ограничений, что кроме примитивных случаев его особо и не используешь... да примитивно, ДО выполнения запроса они обходят клиентом в цыклах все "иерархии" и составляют наборы условий для каждого уровня. А потом Джойнят Все узлы одной иерархии на все узлы другой -- а результат UNION -ALL -ят. Т.е. императивно (в DO-while-ах) они пошивают те самые 30 мб сверток перестановками. если открыть их детище -- мы увидим, что сначала джойнятся выборки с условием Код: sql 1. 2. 3. 4. 5. -- это 4 корня какой- то одной иерархии , наверное : Код: sql 1. Потом -- к ним добавляется Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. -- это скорее всего получено из Код: sql 1. 2. -- вопрос, где они набрали то дикое количество перестановок (комбинаторику) мне пока не ясен Жесть... А я еще считал, что реализация примитивной рекурсии через "системную" табличную функцию, DO WHILE, запросы как строки в качестве параметров и EXEC внутри (у PostgreSQL) или через генерацию аналогичной табличной функции для каждого набора запросов и именем из md5 hash'а (у MS SQL) - перебор. Но читать на клиенте иерархию и embedd'ить ее в запрос это конечно адский ад. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 11:48:36 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
спойлерчотаржу... доставляет.... Ше ,таки, девр (!) ящетаю. 30 мб sql-я -- это не конь чихнул. Хотел промолчать, но после перехода на критику 1С не могу :) Степень уровня кода запроса 1С из первого поста топика превышает все допустимые пределы. Поехали разбирать по косточкам: 1) Прямая рекомендация не использовать ПОЛНОЕ СОЕДИНЕНИЕ 2) ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ОсновныеСредства) рекомендация не использовать значения в запросе, а передавать параметром в запрос. 3) Субконто1.банк.код = ""xxx"" эпичность этого выражения просто зашкаливает. тк а) Субконто1 - составной тип данных и фильтрация по нему сгенерирует соединение еще с каждой таблицой данных б) .банк. - получение данных через точку от полей составного типа решение, пример: В данном запросе используется обращение к реквизитам регистратора. Регистратор является полем составного типа, которое может принимать значения ссылки на один из 56 видов документов. Запрос.Текст = "ВЫБРАТЬ | Продажи.Регистратор.Номер, | Продажи.Регистратор.Дата, | Продажи.Контрагент, | Продажи.Количество, | Продажи.Стоимость |ИЗ | РегистрНакопления.Продажи КАК Продажи |ГДЕ ... SQL-текст этого запроса будет включать 56 левых соединений с таблицами документов. Это может привести к серьезным проблемам производительности при выполнении запроса. Однако, для решения данной конкретной задачи нет необходимости соединяться со всеми 56 видами документов. Условия запроса таковы, что при его выполнении будут выбраны только движения документов "РеализацияТоваровУслуг" и "ЗаказыПокупателя". В этом случае мы можем значительно ускорить работу запроса, ограничив количество соединений при помощи функции ВЫРАЗИТЬ(). Другими словами никакой транслятор запросов и оптимизатор не способен привести в божеский вид изначально кривой код запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 15:20:06 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
laskin82, Это пять. Из разряда вот вам мусоропровод, канализация и электричество, но пользоваться ими не рекомендуется. Для аналогичных задач - есть контейнер на улице, сортир во дворе, и дрова за домом. Другими словами никакой транслятор запросов и оптимизатор не способен привести в божеский вид изначально кривой код запроса. Не поверите, но оптимизаторы запросов самих СУБД именно этим и занимаются. Пытаются понять как то что написал разработчик максимально быстрее выполнить. И у нормальных СУБД там такое количество ухищрений, чтобы можно было просто "сесть и поехать", что видно что они стараются (хотя тоже есть куда расти). Но у 1цэ конечно свой путь, просто не рекомендовать все что можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 15:33:32 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
Nitro_Junkielaskin82, Это пять. Из разряда вот вам мусоропровод, канализация и электричество, но пользоваться ими не рекомендуется. Для аналогичных задач - есть контейнер на улице, сортир во дворе, и дрова за домом. Я бы сказал не так. Есть определенные ограничения и рекомендации. Если их не соблюдать, то получится не хорошо. Вот вам мусоропровод, канализация и электричество, но пользуйтесь ими правильно, а не бездумно. авторНо у 1цэ конечно свой путь Вы бывший/действующий сотрудник компании 1С? Если нет, то не говорите того, чего не знаете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 15:44:15 |
|
||
|
Ошибка при выполнении запроса 1С
|
|||
|---|---|---|---|
|
#18+
laskin82, то-то и оно, что прослойка между кодером и СУБД (под наименованием "плятформа.1с" )привносит сложности (в сложных случаях) , а не упрощает. после дцати лет развития 1С их язык запросов (убожество времён 7) пришел практически к стандартному SQL (за отсутствием некоторых крайне полезных вещей , типа exists(), которых этим недоумкам пока не удалось/захотелось реализовывать) далее: трансляция с этого "почти sql" к реальному SQL производит такие плюхи (см), что по итогу якобы недоумок--1с--кодер должен не просто хорошо понимать SQL, но и детально представлять внутреннюю кухню "транслятора" (недотрахслятора, если быть точнее) и т.д. т.е. по итогу имеем не упрощение пользования системой за счет прослойки, а напротив -- усложнение. //это относится ко многим подобным прослойкам, а не токмо 1С// но в простых случаях накидать запрос в конструкторе зато может и полный недоумок, не знающий не только SQL но и 1с-8-диалекта SQL. //вот за визуальный конструктор запросов , правда до слияния с гробом ээээ, не помню уж его имени, -- их можно было хвалить. хотя и там были недочёты и неловкости// PPS а если ещё и скрестить с вечным секстанством и прочей маркеторийей -- то отстреливать конфигурастов и их пророков как бешеных собак -- единственное верное отношение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2014, 15:50:14 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38820893&tid=1998318]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 398ms |

| 0 / 0 |
