Работаю с MS SQL Server 2000

Оптимизировал однажды одну штуку. Столкнулся с тем что update одной записи выполняется 15мс. Это очень долго. Специфика была такова, что обновлялось много записей, большая часть которых не менялась, но заранее я не мог знать какие именно записи поменялись. Это дело с легкостью оптимизировалось написанием хранимой процедуры, которая сперва доставала запись и БД, сравнивала и только потом обновляла. Можно было триггер написать. В результате необходимость в фиксации транзакции в большинстве случаев отпала, т.к. записи не было, и скорость работы в среднем возросла в 20 раз.

Внимание вопрос! Реализована ли подобная проверка в каких-нибудь СУБД? Если да, то в каких?

ScareCrow
>которая сперва доставала запись и БД, сравнивала и только потом обновляла
открой для себя то что в update можно написать WHERE
Точно! Блин... Ну все равно ж надо where писать

pkarklin авторОптимизировал однажды одну штуку. Столкнулся с тем что update одной записи выполняется 15мс.
А можно увидеть эту "одну" штуку? И чем выполнялись замеры?!

Увидеть нет. Все не так просто на самом деле.
Замеры выполнялись профайлером. И показаниями системного таймера уже непосредственно в приложении.

авторСпецифика была такова, что обновлялось много записей, большая часть которых не менялась, но заранее я не мог знать какие именно записи поменялись.
ТАк что же все-таки происходило на самом деле? Кривонаписанный код с курсором?

Какой курсор? Примерно так. Пользователь выгружает некий справочник, в моем случае в Excel. Но это не важно, с тем же успехом могли быть dbf и т.п.. Правит его у себя и загружает обратно. Зачем его целиком таскать мне самому непонятно.


авторЭто дело с легкостью оптимизировалось написанием хранимой процедуры, которая сперва доставала запись и БД, сравнивала и только потом обновляла.
Какое "это дело"? Кривой код? Доставала из бд и сравновала с чем? Почему надо было обрабатывать по-одной записи, а не обновить все подпадающие под условия обновления?

Мне данные снаружи приходят.

авторВ результате необходимость в фиксации транзакции в большинстве случаев отпала, т.к. записи не было, и скорость работы в среднем возросла в 20 раз.
Эээ... Позаписное обновление и для каждой записи отдельная транзакция?

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

авторРеализована ли подобная проверка в каких-нибудь СУБД? Если да, то в каких?

Какая? Вы имеете ввиду, что СУБД ничего не должна сделать, при отправке ей инструкции вида:


???
Если фактически данные не изменяются, то СУБД не должна их обновлять.

Поймите правильно. Сейчас все работает нормально. Проблем у меня нет. Меня волнует один единственный вопрос, почему, если данные не изменились, СУБД все равно их обновляет и фиксирует транзакцию. Не легче ли их просто оставить как есть? Или здесь какой-то тайный смысл?

pkarklin Самоловских Виталий aka KefirНу все равно ж надо where писать
А то?! А иногда и JOIN несколько раз во FROMе, а еще derived tables и прочую всякую всячину, относящууюся к программированию на T-SQL.

Тупо: есть таблица mytable с полями
ind id
varchar name

В ней запись:
1 ляляля

Делаем так

update mytable
set name='ляляля'
where id=1

выполняется 15 мс и ничего при этом не меняет.

update mytable
set name='ляляля'
where id=1 and name<>'ляляля'

выполняется быстро и ничего при этом не меняет.

Вот это меня и напрягает. Почему я должен писать дополнительное условие, добавлять параметр к запросу, почему это не реализовано на уровне СУБД?

pkarklin
Как в приложении системным таймером можно измерить время выполнения запроса на сервере ?!

Я где-то сказал, что это 1 запрос? Мне в сущности все равно сколько времени выполняется запрос. Меня интересует время реакции системы. Именно про него я говорил, когда имел ввиду в 20 раз.

авторПримерно так. Пользователь выгружает некий справочник, в моем случае в Excel. Но это не важно, с тем же успехом могли быть dbf и т.п.. Правит его у себя и загружает обратно. Зачем его целиком таскать мне самому непонятно.

Абалдеть архитектурка...

А Вы уверены, что ваши пользователи используют вашу систему так как Вы задумывали?

Какой момент Вас интересует? И про "много пользователей" проблема не понятна?!

Запросы от нескольких пользователей в одну транзакцию не запихать. Ну можно, но это изврат. Так что batch-режим в этом случае не поможет.

авторМеня волнует один единственный вопрос, почему, если данные не изменились, СУБД все равно их обновляет и фиксирует транзакцию.
Потому что она делает то, что ей велели (в коде). Как Вы напишите код, так и будет вести себя СУБД.

А вот и нет. SQL относится к языкам сверхвысокого уровня. Я не должен говорить как, я должен говорить что.

авторНе легче ли их просто оставить как есть?
С чего бы СУБД проявлять самодеятельность?!
С того что в ряде случаев это будет быстрее.

SergSuper
Может быть у Вас еще триггер есть? 15мс как-то многовато
Нет. Это чистый апдейт. Сервак старенький, винты медленные. Быстрее не получается.

pkarklin
Знаете за что я не люблю Excel - за то, что он начинает "делать за меня тупую работу". Вставьте значение банковского счета в ячейку на чистом листе и уйдите с нее.
Вы е любите а я люблю. Я же не сказал что сервер обязан делать такую проверку. Я во-первых спросил: "Реализована ли подобная проверка в каких-нибудь СУБД? Если да, то в каких?" Пользоваться ими или нет это сугубо Ваше, в Вашем случае, и мое, в моем, дело.

Вы вскользь упомянули, что на это тратятся дополнительные ресурсы. Единственное конструктивное высказывание по вопросу. Но позвольте, разве при апдейте не копируются страницы, разве искомая запись не попадает в оперативку в любом случае? В моем понимании для такой проверки потребуются лишь несколько дополнительных тактов процессора. Которые в случае фиксации транзакции в БД стоят несоизмеримо меньше, чем скорость записи на жесткий диск. И такая проверка никак не повлияет на скорость выполнения транзакции.

Если я ошибаюсь, то, не могли бы Вы меня просветить?

pkarklinБ.м. Вы мне приведете ссылки на языки, которые в случие явно прописанного в коде (абстрактно):

Var1 = <SomeValue>

будет проверять значение, которое уже есть в Var1 и если оно равно <SomeValue>, не будет выполнять присвоения.
Аналогия неуместна (с) Формула Любви

Если мы держим переменную в памяти, то скорость записи примерно равна скорости чтения. Плюс куча всяких кэшей, короче эффекта никакого.

В случае БД:
1. Скорость чтения ОЗУ заметно выше, чем скорость записи на диск.
2. Запись с большой вероятностью может находиться в ОЗУ.
3. В любом случае происходит чтение страницы с записью и она попадает в ОЗУ.
Таким образом дополнительная проверка может дать (и дает) значительный эффект в производительности.

pkarklin авторЯ где-то сказал, что это 1 запрос? Мне в сущности все равно сколько времени выполняется запрос. Меня интересует время реакции системы. Именно про него я говорил, когда имел ввиду в 20 раз.
Да Вы вообще мало чего говорите техничеком плане. Ведете речь об улучшайзинге "одной штуки" и "этого дела". В результат виноватым оказывается сервер в том что он оказался не прозорливым и не додумал за Вас.

Я не виду речь об улучшайзинге конкретной штуки. И сервер ни в чем не виноват. Каким бы ни был сервер в конечном итоге скорость фиксации транзакции зависит от скорости винтов и от этого никуда не деться.

Вот это о чем-нибудь Вам говорит? "Внимание вопрос! Реализована ли подобная проверка в каких-нибудь СУБД? Если да, то в каких?" Это было в моем 1м сообщении!!!

Меня не интересует Ваше мнение обо мне и о моей системе. Меня интересует ответ на конкретный вопрос: "Реализована ли подобная проверка в каких-нибудь СУБД? Если да, то в каких?"

pkarklin
Т.е. Вы хотите, чтобы все, ято связано с изменением значение поля завязывалось на его значение на уровне ядра, а не на уровне разработки?

ДА! ДА! ДА! Именно об этом я и спрашиваю!!! Вполне логично допустить, что где-то это уже реализовано. Вот я и хочу это знать. Залезть в дебри пары десятков популярных СУБД для одного человека не представляется возможным, поэтому я и задаю этот вопрос на форуме. Может кто-нибудь скажет: "А вот в VasiaPupkinSQL это уже давно реализовано!"

Возможно, когда-нибудь, ANSI и придумет какую-нибудь дополнительную клаузу в UPDATE типа


:)
Будем надеяться.

pkarklin
Дальше, как оказывается, таки был кривой код, улучшайзингом которого Вы занялись, убрав лишние UPDATEты.
Не кривой, а плохо оптимизированный :-\
И, естественно, я бы хотел чтобы оптимизацией занималась СУБД. Не вижу в этом ничего плохого.