Что быстрее - запрос или выборка по спр-ку ? #181682

Надо отобрать элементы спр-ка по опред.условию.Что быстрее - прогнать цикл по выборке элементов или сделать это запросом ?Для вариантов баз - файл-сервер и терминал.

SQL? А вообще-то можно и самому замерить...

Файл-сервер и терминал (два варианта).К сожалению, некогда замерять. Надежда на то, что кто-то уже когда-то замерил.

Файл-сервер и терминал (два варианта).К сожалению, некогда замерять. Надежда на то, что кто-то уже когда-то замерил.

2 А то! Канечна... на твоем компе и сетке как раз вчера и меряли :)

Меряли - от головы до хвоста - 100Mbps, от хвоста до головы - 10Mbps.Как говорится, dual speed.Вопрос не про сетку, а про эску.

ага, замерить время таким образом: Сообщить(ТекущееВремя);крайне сложно и долго :)

В любом случае выборка катит веселее.

??? Мне казалось, что быстрее запрос.А почему ? Или это эмпирическая данность ?

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

ага

>> Надо отобрать элементы спр-ка по опред.условию. Зачем?

:)) !!!

Сие о железа зависит. На более слабых машинах выборка вешает проц, а мало оперативки, но работает быстрее запроса, запрос же жрет больше оперативки, мало проц, но на сильных машинах шустрее.

Когда делаем перебор, то данные вытягиваем программой, написанной на 1С. А вот когда запросом, то данные вытягиваются кодом, написанным на C++    Что будет быстрее?

прямой запрос к SQL по-любому быстрее, а выборка от запроса по скорости не сильно отличается на большой базе (гигов 50 этак)

На этот вопрос давно дан ответ докой NS. С показыванием результатов замеров.Так вот, его резюме: "Выборка бъет запрос". Ветку с подробностями ищите на мисте.

Тоже мне проблему нашли, взяли да померили. Меня дите в тупик поставило вопросом "Кто сильнее - ниндзя-черепашки или человек-паук", причем надо обосновать.

Однажды, от нехрен делать, зашел к франчу якобы устраиваться на работу... И был мне задан именно этот вопрос...Сертифицированный спец (все три сертификата) мой ответ, что выборка быстрее, обсмеял, на что я предложил проверить... После проверки спец сидел, тупо таращив морду лица в монитор - получилось, что я его разложил перед присутствующим клиентом... Финиш наступил через пару минут - с фразой "Понаберут тут лохов с картонками - мне что, их учить, что ли?" покинул помещение....P.S. Обоснование в пользу запроса было именно как в - запрос выполняется на уровне платформы, а выборка - на прикладном уровне ...

(16, 18) Мдя... Подвел меня мой опыт на Фоксе ;)   Но все-таки, почему так? Ведь по уму должно быть наоборот!

те чуваки, которые писали ВыбратьЭлементы + ПолучитьЭлемент круче чуваков, которые писали ВыполнитьЗапросА как тебе понравится тот факт, что у системных объектов 1С поиск свойств/методов сделан точно так же как в примерах ВК, т.е. тупым перебором? Или что дихотомический поиск в таблице значений бывает быстрее, чем системное НайтиЗначение

Все зависит от условия.Например, для условия Лев(Спр.Наименование,4) = "Вася"запрос с условием ("Наименование >= "Вася") и (Наименование < "Васяяяяяяяяя") на большом справочнике порвет выборку как тузик грелку.

(+21) А выборка в немонопольном режиме через XBASE, либо через ADO, а также извраты с НачатьТранзакцию+Спр.НайтиПоНаименованию + Спр.Удалить+ ОтменитьТранзакцию порвут оба способа в 21 еще сильнее :)

Чессгря, не понял, с какой такой радости. У меня на СКЛ выборка из справочника запросом (обычным одноэсовым запросом) делается в десятки раз быстрее, чем перебор. Перебор тупо все вешает на пару минут. Что я делаю не так?

У меня быстрее по Выборке работает. Все отчеты так построены.

При обсуждении скорости запроса не учитываете то, что при его формировании создаются временные таблицы, соответственно его скорость сильно зависит от того, где хранит 1С временные файлы. В то же время при выбратьЭлементы происходит только чтение из таблицы. Вывод: запросы можно существенно ускорить, разместив TEMP на RAM диске. Согласен.

Во многих случаях запросы ужасно неэффективны, потому что перелопачивают ОГРОМНОЕ число лишней информации. Видел я одну простенькую обработочку, где маааленький запросик получал отгрузку по товарам и по дням с несколькими условиями. Выполнялся он жуткое время, и при этом 1с создавала в temp огромные файлы. Переписал его через выборку - получил ускорение в десятки раз.ЗЫ И еще, учтите психологический момент. Во время выборки можно что-то выводить в строку статуса, то есть у пользователя не возникает ощущение "зависшей программы". Когда выполняется запрос, он просто тупо вешает 1с на какое-то время, а уже известно из психологии, что пользователь начинает в этом случае нервничать. ИМХЛ: лучше пусть выборка делается 5 минут, при этом сообщая пользователю, на каком этапе находится - чем запрос будет молчаливо выполняться 3 минуты.

На фоксе select работает в разы дольше, чем перебор.сравни с scan, set filt to, repl all. Это ж перебор? Не согласен. Временные Таблицы, (иначе Курсоры) создаются в ОЗУ и в темпы даже могут и не попасть. ИМХО.

Курсоры-шмусоры, в темп советую посмотреть во время выполнения запроса.

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

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

Если на FP писать запросы к SQL базе, то они быстрее будут в разы летать, особенно это касается запросов с условиями. А если кто иначе думает - пусть пользуется калькулятором электроника, т. к. энергия которую сжирает комп в сто раз ценнее его (в смысле, думающего).

SQL запрос это таже выборка, толко результаты помещаются в отдельную базу с которой потом удобнее работать локально. В этом и состоит преймущество запроса перед выборкой, но на создание зтой базы нужно время, в чем собственно он проигрывает.

Аффтар любит работать локально?

+ 2

Перевожу. Локально - имеется ввиду файл созданный запросом размещается на локальной машине, а не в сети.

Я не про 1С говорю, а про SQL-бд с каким нить FrontEnd. И там локально? Гы-гы-гы.

(34, 37)Оставьте этот жаргон.

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

Проверил, точно в темпе курсор-шмусор появляется. Пробовал ведомость по партии в ТиС формировать. Два файла создаются - dbf+cdx. Оба меняют размер во время выполнения запроса. dbf выросла до 4Мв. В VFP sele * from sc84 никаких темпов не делает, тож проверил.На скорость не повлияло изменение темповой папки в локальный профиль из WinNTTemp. В обоих случаях отчет формировался 43сек.

Такое изменение темпа и не повлияет, т. к. количество операций ввода-вывода одно и то-же, а голова у ХДД скачет не между 30 и 550 цилиндром, а между 60 и 550 т. е. экономится маааленько миллисекунд. Изменение будет, если, например, разместить темп на другом винчестере.

>На фоксе select работает в разы дольше, чем перебор. Ты просто не умеешь его готовить ;) Конечно можно придумать вариант когда, это так. Например выборка из одной таблицы 90% строк. Тут и для select лучше индексы выключить Кстати, если запрос по одной таблице поддавался оптимизации по индексам, то select просто делал так сказать view на эту таблицу, то есть выполнялся _мгновенно_ (!)>сравни с scan, set filt to, repl all. Это ж перебор? Оптимальным вариантом выборки из одной таблицы было вытащить select-ом номера строк и затем уже выбрать нужные строки прямым обращением Но вообще-то запрос это выборка из энного количества связанных таблиц, а не фильтрация одной единственной. Да еще с вычилениями по группировкам, да условиям на группировки

Уже пива успел накатить? :)

На фоксе вообще почти все великолепно работает, и фишек много. Например ZAP просто на низком уровне передвигает конец файла, SELECT * FROM (ttable) просто открывает таблицу в другой области и тд, а запросы шикарно работают, таскал выборки в 1С с помощью его OLEDB провайдера, так все обалденно получается, хотя по многим связкам нет индексов)А Выборка справочника в 1С это всего делов то, открыть нужный SC и подсунуть его в разыменованном виде, потому и быстро))

Интересно, все вышесказанное касается только выборки по справочникам - ил по докам тоже?

Кто быстрее дельфин или верблуд ?

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

2 Этот вопрос периодически поднимается. Его можно уже в FAQ заносить.На DBF в общем случае выборка отрабатывает несколько быстрее.На SQL - зависит от запроса.Грамотно составленный запрос с простыми условиями на переменные запроса отрабатывает в разы быстрее выборки (потому как отрабатывается на сервере).На больших объемах данных может и в десятки раз быстрее выполняться.Если условия хитрые или через точку, тогда может получиться и наоборот (1С в этом случае может демонстрировать чудеса неоптимальности).

+1У меня есть справочник,в котором около 500 000 записей, запрос(1с-овый) выполняется по нему практически мгновенно, а через выбратьэлементы это ужос.Ради справедливости стоит отметить, что версия скульная.

+естественно имеется ввиду запрос с условиями.

Видимо, мы с тобой где то тупим, т.к. ответ на вопрос остался без ответа. Либо у нас линейки не достаточно длинные, как у . :)

Ещё есть объект "БухгалтерскиеИтоги". На больших объёмах его вобще не дождаться. Приходиться пользовать обычные запросы. А на аттестации по бухии меня дядька пожурил, мол, нехорошо, надо через бухитоги.Пришлось переделывать всё в экстренном порядке.Давно эт было правда....

2 фигня какая-то... Видно, что с бух-компонентой вы не работаете.

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

2 После ваших реплик - пожалуй.Выигрыш у обычного запроса будет, пожалуй, лишь в запросе по проводкам/операциям с условиями. А именно с БУХИТОГАМИ бухзапрос работает и корректнее и быстрее. Я говорю про SQL, за DBF ручаться не могу - давно не работал.

Перегонял жутко переделанную бухгалтерию 7.7. из дбф под SQL заметил что SQL с большим объемом класно работает. А если построить красивый запрос, один запрос. Вместо 10 выборок. Тогда обращаясь только к этому запросу аналитика выходит быстро и красиво. Ну а в местах где был вложенный в выборку запрос по выборке... Вставить в таком же ключе запросы к SQL то и будет все медленно медленно... Ну конечно если нужно вывести 5ть строчек тогда запрос быстрее. Может все к месту и времени? Маленькое всегда перерастет в большое потому запрос круче

"А именно с БУХИТОГАМИ бухзапрос работает и корректнее и быстрее".Вы их ещё и классифицируете? Вот это как по-Вашему БУХИТОГИ или нет?.............

+ Раньше я тоже активно пользовался бухитогами, но на огромной скульной базе они действительно работают ужасно.

Самый быстрый способ - сложный прямой запрос на 1C++ к SQL серверу на хорошем железе, причем в запросе делается как выборка так и фильтровка, а клиенту перекидывается готовый результат.Самый тормозной - в файловом режиме на сетке 100Mb при 20 активных подключениях делать запрос 1С на бух итоги с целью получить оборот.Промежуточный вариант: Бух итоги но нацеленные на готовые данные промежуточных итогов: обороты, остатки, без сложных выборок и фильтров, типа получения самих документов.Выборка бьет запрос, если берется 3 элемента из 3000 с поиском по индексированному реквизиту, например: НайтиПоРеквизиту.Народ !!!!!!!!Назовите универсальный алгоритм сортировки, который был бы самым быстрым во всех возможных случаях: пузырьковой сортировки, быстрой сортировки, бинарные ....Банальный перебор всегда медленнее поиска в предварительно подготоволенном массиве: бинарные деревья например.Вывод. Нет смысла сравнивать запрос и программную выборку вообще. Это глупо. Давайте поставим жесткие условия задачи и только тогда начнем рассматривать скорость.Несколько вариантов выборки сделано потому, что ситуации бывают разные :). Это окончательный вердикт.