h
или это подругому делается?
Size: a a a
2020 July 15
DB
Для бд админа ? Или в таблице Админ ?
h
в таблице юзер админ
DB
h
в доке так и написано запустить сид дату
DB
Написать update запрос, не ?
h
пойду гуглить
ЕИ
Я тут изобрёл офигенный класс для быстроого массового обновления в базе данных (MS SQL Server). В боевую уже неоднократно его применил, это просто окончательное решение вопроса массового обновления данных из C# приложения.
Забавно, что никто не додумался раньше, вроде.
Что делает. Берёт На входе большой массив сущностей EF.
На выходе генерирует большой SQL скрипт примерно такого содержания:
1. Объявление временной переменной табличного типа (более удобный вид временной таблицы)
2. Инсёртит туда все обновляемые строки
3. Далее конструкция Transact Sql MERGE, в качестве источника - темповая таблица из переменной, в качестве цели обновляемая таблица. Ну и условия, какая секция таблицы обновляется
По сравнению с таким обновлением через Entity Framework прирост в производительности - уровня "всё вместе работает вместо полчаса-час за пару минут", когда там под сотню тысяч строк может обновляться
Забавно, что никто не додумался раньше, вроде.
Что делает. Берёт На входе большой массив сущностей EF.
На выходе генерирует большой SQL скрипт примерно такого содержания:
1. Объявление временной переменной табличного типа (более удобный вид временной таблицы)
2. Инсёртит туда все обновляемые строки
3. Далее конструкция Transact Sql MERGE, в качестве источника - темповая таблица из переменной, в качестве цели обновляемая таблица. Ну и условия, какая секция таблицы обновляется
По сравнению с таким обновлением через Entity Framework прирост в производительности - уровня "всё вместе работает вместо полчаса-час за пару минут", когда там под сотню тысяч строк может обновляться
ЕИ
Работает даже куда удобнее, чем пресловутый Bulk Insert
ЕИ
И быстрее
ЕИ
ANSI SQL - это замечательно
Но иногда лучше генерить скрипт, который использует нестандартные конструкции конкретной базы данных
Но иногда лучше генерить скрипт, который использует нестандартные конструкции конкретной базы данных
ЕИ
MERGE очень мощная конструкция в SQL Server
АМ
Я тут изобрёл офигенный класс для быстроого массового обновления в базе данных (MS SQL Server). В боевую уже неоднократно его применил, это просто окончательное решение вопроса массового обновления данных из C# приложения.
Забавно, что никто не додумался раньше, вроде.
Что делает. Берёт На входе большой массив сущностей EF.
На выходе генерирует большой SQL скрипт примерно такого содержания:
1. Объявление временной переменной табличного типа (более удобный вид временной таблицы)
2. Инсёртит туда все обновляемые строки
3. Далее конструкция Transact Sql MERGE, в качестве источника - темповая таблица из переменной, в качестве цели обновляемая таблица. Ну и условия, какая секция таблицы обновляется
По сравнению с таким обновлением через Entity Framework прирост в производительности - уровня "всё вместе работает вместо полчаса-час за пару минут", когда там под сотню тысяч строк может обновляться
Забавно, что никто не додумался раньше, вроде.
Что делает. Берёт На входе большой массив сущностей EF.
На выходе генерирует большой SQL скрипт примерно такого содержания:
1. Объявление временной переменной табличного типа (более удобный вид временной таблицы)
2. Инсёртит туда все обновляемые строки
3. Далее конструкция Transact Sql MERGE, в качестве источника - темповая таблица из переменной, в качестве цели обновляемая таблица. Ну и условия, какая секция таблицы обновляется
По сравнению с таким обновлением через Entity Framework прирост в производительности - уровня "всё вместе работает вместо полчаса-час за пару минут", когда там под сотню тысяч строк может обновляться
А не так работает https://www.nuget.org/packages/Z.EntityFramework.Extensions.EFCore/
АМ
Только платная она
ЕИ
>BulkMerge
Думаю, аналогично
Генерирует оптимальный для базы SQL скрипт
Думаю, аналогично
Генерирует оптимальный для базы SQL скрипт
ЕИ
Будет свободное время, надо бы довести класс до товарного вида, в смысле из используемого на практике наколеночного решения сделать из него либу, да опубликовать на гитхабе
Сам подход показал себя очень удачным на практике, в больших базах и при больших объёмах обновления
Сам подход показал себя очень удачным на практике, в больших базах и при больших объёмах обновления
ЕИ
Причём сделал это уже от безысходности. Когда надо было хоть как-то оптимизировать это дело, а ничего уже из голимого EF нечего было выжать
От безысходности сделал генерацию скрипта, который через темповую таблицу и MERGE обновляет большую секцию данных
И сам присел от того, насколько удачно в плане производительности вышло
От безысходности сделал генерацию скрипта, который через темповую таблицу и MERGE обновляет большую секцию данных
И сам присел от того, насколько удачно в плане производительности вышло
ЕИ
Не жалкие проценты улучшения, и даже не в разы, а в десятки раз скорость апнулась
ЕИ
Не поверил своим глазам сначала после первых тестов на скорость
ЕИ
Думал что-то некорректно делает. А нет, делает ровно всё как надо с базой, только в десятки раз быстрее