Комментарии 17
А нельзя отдельно представить только начало графика?
Сейчас можно судить только о 2й половине тестов, т.к. 1-ая на графиках не проявилась.
Сейчас можно судить только о 2й половине тестов, т.к. 1-ая на графиках не проявилась.
спасибо за обзор. сам недавно столкнулся с такой задачей, но проводить сравнение методов не было времени
Спасибо, отлично! А в процедуре происходило какое-нибудь действие? Ведь это тоже важно как обработать потом параметры.
ну да, но если учесть относительность тестов друг друга, то этот функционал можно вынести за скобки и сократить. тестируется лишь адекватный переход в t-sql, то бишь параметр преобразуется в список и заполняет временную переменную.
Смотрите о чем я. Когда используется SqlBulkCopy или table-valued parameters — то у вас уже на входе в процедуру есть таблица, с которой можно работать, когда varbinary или xml — вам еще нужно создать эту таблицу (или не нужно создавать, а сразу использовать что есть). То есть в тестах SqlBulkCopy (.net app -> #table -> @table -> процедура) сравнивался с xml (.net app -> xml -> @table -> процедура), так? Хотя может приведение к @table — это уже окончательная операция. Интереснее, наверное, было бы что-то вроде «insert into @table (id) select t1.id from @temptable t1 left join @table t2 on t1.id = t2.id where t2.id is null» (то есть вставка значений, которых еще не было), ну и это само собой нужно бы сделать несколько раз и взять среднее. Тут мне кажется уже будут другие результаты, хотя нужно пробовать.
вы правы в том, что в случаях с балккопи и табличным типом у меня нет необходимости создавать временную переменную, можно использовать уже пришедший параметр.
если следовать вашей логике и создавать прикладной функционал в тестируемых хранимых процедурах, то получается, что сервер в любом случае будет делать index seek при подстановке в join \ select in. стало быть если откинуть этот функционал, то «лишними» действиями относительно балккопи\табличный тип является выделение памяти.
значит, если сделать в балкопи \ табличном типе такое же выделение памяти, как и в других методах, то тесты подводятся к общему знаменателю и прикладным функционалом тестируемых хранимых процедур можно пренебречь.
если следовать вашей логике и создавать прикладной функционал в тестируемых хранимых процедурах, то получается, что сервер в любом случае будет делать index seek при подстановке в join \ select in. стало быть если откинуть этот функционал, то «лишними» действиями относительно балккопи\табличный тип является выделение памяти.
значит, если сделать в балкопи \ табличном типе такое же выделение памяти, как и в других методах, то тесты подводятся к общему знаменателю и прикладным функционалом тестируемых хранимых процедур можно пренебречь.
У вас в таблице нет опечатки?
По данным в таблице получается, что для 1000 элементов table передача самая медленная ( со значением 65).
По логике больше похоже на 6.5.
По данным в таблице получается, что для 1000 элементов table передача самая медленная ( со значением 65).
По логике больше похоже на 6.5.
А за статью больше спасибо. Этот вопрос встает у многих, если не у каждого разработчика.
Вопрос актуальный, особенно для начинающих разработчиков, спасибо.
Очень познавательно и интересно. Еще хотелось бы увидеть на сколько медленней работает тривиальный insert в цикле?
И еще хочу добавить один минус table метода — хотя по перфомансу и удобству он лучше остальных но к сожалению драйвер для него есть только под .Net.
И еще хочу добавить один минус table метода — хотя по перфомансу и удобству он лучше остальных но к сожалению драйвер для него есть только под .Net.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тесты методов передачи списковых переменных в хранимую процедуру MS SQL 2008