|
07.12.2009, 13:28 | #1 |
Участник
|
Цитата:
Сообщение от Сисой
В ряде случаев (отбор по критерию "равно") 1С просто решает эту проблему по другому. В языке запросов 1С есть оператор В (IN), который умеет принимать в качестве операнда список объектных значений. Такой запрос автоматически транслируется 1С в объединение кучи одинаковых подзапросов с UNION ALL и подстановкой разных значений в условия сравнения. План запроса один и тот же.
Если кто-то может дать ссылки или объяснить в двух словах (проще, чем в статье), пожалуйста, сделайте это. Хнык-хнык-хнык... Опять начали что ли? Опять попытка смазать разницу между "уже есть" и "можно сделать"? Да какая разница кто кому на каких курсах говорит? В типовых запросы в цикле есть? Есть. Надо исправлять? Надо. При чем здесь экзамен 1С:СПециалист? Кроме того, мы говорим о платформе. В том, то и дело, что в Аксапте иногда запрос в цикле выполняется быстрее и удобнее, нежели один сложный запрос. За счет кэширования. Например, Для каждого клиента/группы, для каждой номенклатуры/группы, для каждого рабочего центра и т.п... могут быть настроены свои правила разноски по счетам. Правила достаточно сложные. Объектов, для которых могут быть указаны правила разноски мжет быть до нескольких десятков. Неужели создавать один суперсложный запрос для таких вещей? Нет, отвечает Аксапта. Сделайте правильный запрос для выборки объектов. А правила разноски запрашивайте внутри. Поскольку правила скорее всего полностью попадут в кэш, то внутренние запросы выполнятся очень быстро. Что кардинально упрощает программирование и взаимодействие объектов. Псевдокод: X++: while select , , , , , , ... where... { = (); = (); = (); ... (, , ...); } Хочу обратить внимание, что код внутри цикла может быть распределен по другим методам, другим классам. Но он все равно будет быстрым из-за кэширования. Хочу также обратить внимание, что правила могут быть любыми - не только счета. Но и правила расчета себестоимости, правила резервирвоания, правила работы со складскими аналитиками, куча настроек в производстве, офигенная куча настроек лдя сводного планирования... и т.п. Понятно, что механизм кэширования тоже надо уметь настраивать. Понятно, что механизм кэширования не спасет в случае больших таблиц. У этого механизма есть своя область применения, где он работает очень хорошо. В 1Се этого просто нет. Поэтому разработчики конфигураций вынуждены правила просто зашивать в код. Чтобы избежать ddos-атак на SQL. Или вручную кэшировать. Цитата:
В 1С просто не делают по-настоящему настраиваемых конфигураций. Только программируемые Цитата:
Отобрать и брать - это отдельный код, который тоже надо программировать. за размером temptableтоже надо следить вручную |
|
07.12.2009, 14:05 | #2 |
Administrator
|
Цитата:
Сообщение от Сисой
В ряде случаев (отбор по критерию "равно") 1С просто решает эту проблему по другому. В языке запросов 1С есть оператор В (IN), который умеет принимать в качестве операнда список объектных значений. Такой запрос автоматически транслируется 1С в объединение кучи одинаковых подзапросов с UNION ALL и подстановкой разных значений в условия сравнения. План запроса один и тот же.
Цитата:
Сисой (как я понимаю) - говорит о том, что если нужно выбрать дискретные данные из таблицы (допустим выбрать 10 клиентов поименно), то 1С поддерживает оператор T-SQL IN и запрос, отсылаемый на сервер принимает вид: SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM IN ('Клиент1', 'Клиент2', 'Клиент3', ..., 'Клиент 10') Т.е. вместо того, чтобы слать 10 запросов вида SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = 'Клиент1' шлется одна вышеприведенная инструкция (это к слову о том, что 1С считает что лучше один большой запрос, чем 10 маленьких). Но вот мне кажется, что если в коде в 1С последовательно написать строчки: SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = 'Клиент1' и SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = 'Клиент2' То в БД уйдет 2 запроса и для каждого запроса будет строиться план. При этом mazzy говорит о том, что AX (если в коде будут написаны 2 такие же строчки) отправит в БД тоже 2 запроса: SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = :p1 и SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = :p1 А уже вместо переменной p1 ПОСЛЕ построения плана запроса будет подставлено конкретное значение. Разница между АХ и 1С тут будет в том, что план запроса в АХ будет строиться только 1 раз, а время, затрачиваемое БД на построение плана запроса и подстановку значения переменной несоизмеримо на больших объемах данных. А вот тут кстати - есть "хорошая новость" любителям временных таблиц (это относится к любым системам). Переливая данные во временную таблицу - мы теряем производительность на больших объемах данных, т.к. 1) Выборки из постоянных таблиц м.б. неполными (например формы в АХ тянут не все записи из таблицы, а только видимые + небольшой хвостик). А переливка во временную таблицу м.б. гораздо большего кол-ва записей, чем отображаемые. Но это больше к АХ относится как мне кажется 2) Помимо размера временной таблицы - никто не говорит про индексы. Переливая из постоянной таблицы данные во временную - мы фактически отказываемся от использования индексов - что естественно отражается на произовдительности на больших объемах данных. Подчеркну - если во временной таблице - небольшое кол-во данных - то указанные мною ограничения отсутствуют. Но как только во временную таблицу будут переливаться тысячи записей - то ограничения почуствуются
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 07.12.2009 в 14:08. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
Теги |
1c, платформа, сравнение систем |
|
|