Comments 11
Советую также посмотреть в сторону Dapper. Особенно удобно использовать его для оптимизации запросов на чтение, но и для update/insert он тоже подойдет.
А почему бы не использовать для вставки и обновления данных хранимые процедуры? Почему именно метод add(..), ведь тот же EF может работать с хп. Большое количество данных в БД можно передать, например, в xml формате, а там, уже в базе, распарсить и сохранить с помощью хранимой процедуры. Как такой вариант?
Это несколько ломает саму концепцию entity framework, нет?
Если парсинг приведет к выполнению INSERT запроса для каждой записи — то мы получим время выполнения на уровне AddRange, а то и выше, при этом трудоемкость реализации вырастает на порядки.
Конечно же нет. Данные можно вставить скопом, используя тот же merge. Трудоемкость реализации наверное просто дело опыта. Имхо, удобнее пробросить набор данных на технологию, которая предназначена для работы с ними и дальше ими оперировать уже в ней.
Дело вкуса. SqlBulkCopy подходящая технология, вдобавок обеспечивающая максимальную производительность. Т.к. она не выполняет SQL вообще, а работает напрямую с файловой структурой БД. Как мне кажется, написать сравнимый по скорости запрос вряд ли возможно физически, что и подтверждается сравнительными тестами из различных источников. С другой стороы, если конкретная задача хорошо ложится на вашу схему, то почему нет. Во многих случаях даже AddRange достаточно, а преждевременная оптимизация — зло.
Поддержу предыдущего комментатора, по работе вынужден сталкиваться с EF, даже 6тая версия — какие-то наборы архитектурных костылей. Когда была возможность выбирать — использовал PetaPoco и Даппер — ничуть не жалею. Вообще громоздить абстракцию поверх и так уже абстрактного языка SQL — это коряво. А все эти трекинги объектов и контексты — ну не знаю, для меня это издевательство и переусложнение простой задачи — прочитать данные или записать данные. SQL надо знать и надо им пользоваться, а не придумывать велосипеды чтобы его избежать. А аргументы про то как легко сменить базу данных когда у вас есть абстракция — вот честно, кто хоть раз на больших проектах менял базы данных ???
Отдельное слово про мерджи — лично я их не очень люблю, и по-возможности стараюсь избегать. Ибо с ним ОЧЕНЬ просто накосячить с индексами, в результате вместо повышения производительности будет происходить фуллскан со всеми вытекающими. Очень часто видел скрипты, которые после переписывания на insert + update давали прирост просто на порядки. Тогда как средний выигрыш MERGE со всеми правильно написанными индексами раза в 2 выше. В результате либо стабильная производительность, но чуть ниже, либо более высокая, но которую можно элементарно сломать. Даже если изначально БД спроектирована правильно, придут новые столбцы/требования, и человек, который не так хорошо разбирается в индексах перестроит запросы на фулскан и все.
Небольшая отсылка.
Небольшая отсылка.
Sign up to leave a comment.
Entity Framework: повышаем производительность при сохранении данных в БД