Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Предположим у меня есть две разные таблицы данных между которыми надо синхронизировать (частая задача при испорте, не EAV таблицы, а обычные плоские где каждый атрибут отдельная колонка)

Для простоты предположим что есть 3 колонки и может быть изменено любое количество столбцов.
Предположим что мы нашли строки в которых есть изменения.

Как оптимальнее написать update

1) отдельными запросами по каждому атрибуту/колонке писать update каждый со своим условием по этому атрибуту
2) один апдейт и перезаписывать каждый раз на старое значение (*тут ещё ворос как найти строку хоть с одним изменением... or or or или хитрая манипуляция с union и count() having count(1) < 2)
...
3) вообще удалить и вставить все строки

Как бы не хотелось бы и писать слишком много апдейтов, делать отдельные транзакции и не хотелось бы делать пустые апдейты.

Интересуют мысли и их логика )

Заранее спасибо!
17 фев 15, 15:34    [17277022]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
Glory
Member

Откуда:
Сообщений: 104751
NIIIK
*тут ещё ворос как найти строку хоть с одним изменением

Вообще-то для этого должно быть специальное поле в таблице
17 фев 15, 15:39    [17277066]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10233
Блог
PK + ChangeTracking
17 фев 15, 15:40    [17277070]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Glory,

Не понимаю ответа.
Это задача синхронизации данных между двумя независимыми источниками.

По сути тот же CSV файл загрузился во временную таблицу, а дальше работаешь...

Хотя и в хранимой процедуре бывает что передаётся "список строк". Но то по сути та же задача.

Для одной строки то ещё можно сформировать динамическим СКЛем "нужный апдейт" и если некоторые параметры не отличаются от значений "по умолчанию" у процедуры (или тупо слектом узнаёшь текущие).

А тут уже в словиях задачи "есть две таблицы с данными которые надо синхронизировать

и запросы в духе

update t
     set t.field1 = s.field2,
          t.field2 = s.field2
          ...
  from targetTable t
 inner
   join sourceTable s
     on s.. = t..
where s.field1 <> t.filed1 
    or  ..


или такие же "одиночные по каждому полю" писать не хочется.
17 фев 15, 16:03    [17277271]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
напишите merge интрукцию
17 фев 15, 16:05    [17277283]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
Glory
Member

Откуда:
Сообщений: 104751
NIIIK
Это задача синхронизации данных между двумя независимыми источниками.

И вы думаете, что для этой задачи схема данных не должна специально разрабатываться ?
17 фев 15, 16:05    [17277284]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Knyazev Alexey
PK + ChangeTracking

Сильно не понял ответ.
17 фев 15, 16:06    [17277287]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Maxx
напишите merge интрукцию


merge или update/insert вообще не вопрос.

Вопрос в том что бы определиться как обновлять лучше.
1) поколоночно с кучей транзакций и операторов
2) сразу все колонки с фейковым апдейтом на старое значение и одним опратором update.
17 фев 15, 16:07    [17277299]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
2)
NOT EXISTS(SELECT s.f1,s.f2,... INTERSECT SELECT t.f1,t.f2,...)


MERGE
не предлагать?
17 фев 15, 16:09    [17277316]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
Glory
Member

Откуда:
Сообщений: 104751
NIIIK
Вопрос в том что бы определиться как обновлять лучше.
1) поколоночно с кучей транзакций и операторов
2) сразу все колонки с фейковым апдейтом на старое значение и одним опратором update.

Все зависит от количества обновляемых данных
100 транзакций по 1 записи лучше одной транзакции на 1 000 000 записей
но 1 000 000 транзакций по одной записи хуже одной транзакции на 1 000 000 записей
17 фев 15, 16:10    [17277320]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
iap,

это как вариант поиска (для условия)

О операторе Merge я знаю и уме им пользоваться )

Я говорю о том что в цслови что merge что update будет написано много колонок (если один) и многие "обновления данных" будут фейковыми, либо это будет много опреаторов update, но зато из-за одного изменённого атрибута не будут апдейтится куча кононок

MS SQL как-нибудь можно научить что бы он "не выполнял" обновления в случая

update t
set t.filed1 = t.field1

или t.field1 = s.field1 или t.filed1 = @filed1 когда значение по факту не меняется?
17 фев 15, 16:13    [17277338]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Glory,

В том и дело что грядут "гавно данные", что даже мысль ингода возникает "Delete + Insert" делать. Без всяких условий и т. п.
Там же ещё и при поиске "а не изменилось ли что-нибудь" условие не малое (или не малое количество). Индексов точно "не напасёшься", да и ДМЛ операцию притормозят. Сейчас пока только интуитивно решаю (склоняюсь) к "много транзакций".

Хотя если бы это была хранимка которая обновляет один эземпляр (ну или несколько переданых пользователем) обычно пишу одним update и перезаписыванием на старое значение.
17 фев 15, 16:18    [17277377]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
NIIIK,

напишите триггер INSTEAD OF UPDATE и апдейтите только нужные поля в нужных строках.
17 фев 15, 16:18    [17277381]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
iap
NIIIK,

напишите триггер INSTEAD OF UPDATE и апдейтите только нужные поля в нужных строках.
Хотя, какая разница, писать исходный UPDATE или UPDATE в триггере...
17 фев 15, 16:20    [17277394]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 21242
NIIIK
MS SQL как-нибудь можно научить что бы он "не выполнял" обновления в случая
[skipped]
когда значение по факту не меняется?

Нет, вот ты в самом деле думаешь, что сервер, как клинический идиот, обновляет записи по одному полю? Поверь, это не так, обновление идёт в памяти, а из грязного кэша данные сбрасываются на диск вполне себе вменяемыми блоками, но не менее блока, в который запись входит полностью. И неважно, сколько полей обновлено в записи одной инструкцией - всё равно будет переписываться не меньше чем вся запись. Скорость обновления данных в памяти на несколько порядков быстрее записи изменённой записи на диск - так что количеством изменяемых полей можно смело пренебречь. А вот устраивать обновления тремя запросами по одному полю - неразумно, потому как в этом случае суммарное количество записываемых блоков грантированно не меньше, чем при обновлении всех полей сразу одним запросом.
17 фев 15, 16:20    [17277398]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Akina
NIIIK
MS SQL как-нибудь можно научить что бы он "не выполнял" обновления в случая
[skipped]
когда значение по факту не меняется?

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


Ну вообще думал что просто "обнвляет"

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

Я только рад если можно "одинм запросом" записывать данные.

Собственно за этим я сюда и пришёл с вопросом.
17 фев 15, 18:24    [17278080]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
NIIIK
Грубо говоря как если бы в коде присваивал значение переменной такое же как в ней сейчас хранится.
При обновлении переменной в коде обновятся не только нужные биты, но вся переменная. И даже целиком слово или даже строка (единица кеширования).
Всё зависит от конкретного устройства.

Вот сиквел так устроен, что не может обновить меньше страницы (8кб)
То есть обновление 10 полей в одной записи - это 10 раз обновить страницу, в которой эта запись.
А если обновить 10 полей в каждой из 100 записях, которые влезли на страницу, то сервер 1000 раз перепишет страницу. А в лог транзакций попадёт ещё больше.

Это упрощённо, может где то будет и меньше обновлений, но лучше всё таки написать правильно, то есть обновлять все поля записи, и сразу пакетом для группы записей.
17 фев 15, 18:39    [17278136]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
o-o
Guest
alexeyvg
А если обновить 10 полей в каждой из 100 записях, которые влезли на страницу, то сервер 1000 раз перепишет страницу. А в лог транзакций попадёт ещё больше.

вот как раз в лог он страницы целиком не пишет.
я про update сейчас, не про reorganize / rebuild in full recovery model
17 фев 15, 19:00    [17278198]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
alexeyvg,

ещё раз, для тупых,

если я напишу update в духе

update t
     set t.field1 = s.field2,
          t.field2 = s.field2


или
update t
    set t.field1=t.field1 --сам себя
         t.field2 = coalesce(@var1, @var2, t.field2), --когда обе переменные is NULL
...

Это никак не нагрузит СКЛ сервер, даже если я для всей таблицы этот апдейт выполню?
17 фев 15, 19:23    [17278277]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
NIIIK,

при условии что первый апдейт так же не меняет фактически значения.
17 фев 15, 19:24    [17278284]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
o-o
вот как раз в лог он страницы целиком не пишет.
Ну да, в лог по разному, в зависимости от всяких тонкостей.
NIIIK
Это никак не нагрузит СКЛ сервер, даже если я для всей таблицы этот апдейт выполню?
Не нагрузит. Он всё таки проверяет, изменилась поле, или нет.

Точнее, нагрузит, но только чтением: читать записи он будет, несмотря на ненужность этого.
Во вторых, я говорил о случае, когда записи всё таки меняются.
17 фев 15, 20:00    [17278354]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
SERG1257
Member

Откуда:
Сообщений: 2873
Вариант 2 однозначно.
Еще один момент - если у вас не три колонки, а много больше, то можно завести еще одну и совать туда хэш от колонок (CRC, MD5 или еще что нибудь) и сравнивать только ее.
17 фев 15, 20:50    [17278496]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
SERG1257,

это да, хорошая в целом идея, использовал даже.
17 фев 15, 22:18    [17278728]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
NIIIK
SERG1257,

это да, хорошая в целом идея, использовал даже.
Меня сейчас закидают экскрементами, но для этих целей есть специализированные инструменты. Например, GoldenGate (он денег стоит).

1) С одной стороны это CDC (он черпает изменения из логов базы)
2) С другой стороны это средство гарантированной доставки, а значит не произойдет потери данных при передаче от системы к системе
3) Ну и применение изменений к целевой системе он делает очень умно - обновление генерируется только по полям, которые изменились. Плюс обновление делается пакетными операциями, что многократно снижает нагрузку на transactional log.

Можно самостоятельно взять дистрибутив. Пошаговая инструкция по настройке вот тут. Общая информация тут.
17 фев 15, 23:04    [17278871]     Ответить | Цитировать Сообщить модератору
 Re: Наиболее оптимальное обновление данных.  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Alexander Ryndin,

да тут это как снежками.

Спасибо, изучу в общих целях, может следующим понадобится, но не буду применять в этой задаче.

Тут я ограничен стандартными методами МсСКЛ и по сути вопрос "какой апдтей более эффективный".
17 фев 15, 23:17    [17278913]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить