VS
ну это не док-во
Size: a a a
2020 July 16
AD
Т-34 85
базу чего?
надеюсь на как минимум рекомендательных систем
VS
любое приложение прикрепленное к твоему твиттер аккаунту может это постить
VS
Любое ломаешь и постишь
VS
Допустим
AD
сотни самых вкусных акков были в одном сервисе ? врятли
VS
Взлом сотрудника с правами постить твиты от чужих лиц? 100% инфа
AD
Взлом сотрудника с правами постить твиты от чужих лиц? 100% инфа
врятли . на уровне таких компаний , есть так называемые леса , доступ к критическим местам есть только из леса.
VS
ты же постил инфу что взломали сотрудника, а теперь тебе "вряд ли". не пойму тебя
AD
ты же постил инфу что взломали сотрудника, а теперь тебе "вряд ли". не пойму тебя
где ? я такого не постил
AD
это под рукой скрин для ответа парню , кого взломали , чтобы не писать имена
VS
понял, окей
Dv
Я тут изобрёл офигенный класс для быстроого массового обновления в базе данных (MS SQL Server). В боевую уже неоднократно его применил, это просто окончательное решение вопроса массового обновления данных из C# приложения.
Забавно, что никто не додумался раньше, вроде.
Что делает. Берёт На входе большой массив сущностей EF.
На выходе генерирует большой SQL скрипт примерно такого содержания:
1. Объявление временной переменной табличного типа (более удобный вид временной таблицы)
2. Инсёртит туда все обновляемые строки
3. Далее конструкция Transact Sql MERGE, в качестве источника - темповая таблица из переменной, в качестве цели обновляемая таблица. Ну и условия, какая секция таблицы обновляется
По сравнению с таким обновлением через Entity Framework прирост в производительности - уровня "всё вместе работает вместо полчаса-час за пару минут", когда там под сотню тысяч строк может обновляться
Забавно, что никто не додумался раньше, вроде.
Что делает. Берёт На входе большой массив сущностей EF.
На выходе генерирует большой SQL скрипт примерно такого содержания:
1. Объявление временной переменной табличного типа (более удобный вид временной таблицы)
2. Инсёртит туда все обновляемые строки
3. Далее конструкция Transact Sql MERGE, в качестве источника - темповая таблица из переменной, в качестве цели обновляемая таблица. Ну и условия, какая секция таблицы обновляется
По сравнению с таким обновлением через Entity Framework прирост в производительности - уровня "всё вместе работает вместо полчаса-час за пару минут", когда там под сотню тысяч строк может обновляться
На прошлой работе была самодельная CMS, которая большие запросы именно в таком режиме делала. И, вроде, если данных чуть поменьше, то могла ещё через огромный XML их обработать.
Dv
В смысле взломали?
Dv
То есть мне не вернут мои 40 тыщ баксов в двойном размере?
D
Я тут изобрёл офигенный класс для быстроого массового обновления в базе данных (MS SQL Server). В боевую уже неоднократно его применил, это просто окончательное решение вопроса массового обновления данных из C# приложения.
Забавно, что никто не додумался раньше, вроде.
Что делает. Берёт На входе большой массив сущностей EF.
На выходе генерирует большой SQL скрипт примерно такого содержания:
1. Объявление временной переменной табличного типа (более удобный вид временной таблицы)
2. Инсёртит туда все обновляемые строки
3. Далее конструкция Transact Sql MERGE, в качестве источника - темповая таблица из переменной, в качестве цели обновляемая таблица. Ну и условия, какая секция таблицы обновляется
По сравнению с таким обновлением через Entity Framework прирост в производительности - уровня "всё вместе работает вместо полчаса-час за пару минут", когда там под сотню тысяч строк может обновляться
Забавно, что никто не додумался раньше, вроде.
Что делает. Берёт На входе большой массив сущностей EF.
На выходе генерирует большой SQL скрипт примерно такого содержания:
1. Объявление временной переменной табличного типа (более удобный вид временной таблицы)
2. Инсёртит туда все обновляемые строки
3. Далее конструкция Transact Sql MERGE, в качестве источника - темповая таблица из переменной, в качестве цели обновляемая таблица. Ну и условия, какая секция таблицы обновляется
По сравнению с таким обновлением через Entity Framework прирост в производительности - уровня "всё вместе работает вместо полчаса-час за пару минут", когда там под сотню тысяч строк может обновляться
это будет работать пока у тебя условно размер БД не больше пары гигов. Перелив всех записей БД из одних таблиц в другие все равно надо делать транзакционно для всех таблиц, т.к. нельзя чтобы миграция поломалась посередине - а это вызовет адовый рост журнала транзакций.
D
тоесть миграция подобным способо будет кратно (относительно размера БД) и гарантированно увеличивать размер журнала транзакций.