Работаю с 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ты.
Не кривой, а плохо оптимизированный :-\
И, естественно, я бы хотел чтобы оптимизацией занималась СУБД. Не вижу в этом ничего плохого.

ЧАЛ
В отсутствии транзакций действительно такое пожелание возможно, но тогда это уже не будет полноценная СУБД. Так что тут проблемы глубже. Вся пакость в том, что в общем случае два следующие запроса могут привести БД к разным состояниям:



Это легко продемонстрировать. После первого запроса гарантировано все поля будут равны 'lalala'. А вот после второго запроса это вовсе не гарантировано, поскольку те поля, который уже были равны 'lalala' (а потому исключены) могут быть в процессе выполнения приравнены к какому-то другому значению (конкурентным запросом). Такие ситуации часто встречаются, например, с неравенствами тоже подобного рода проблемы могут возникнуть.

Угу. Да проблема. Но думаю что, если оптимизация пойдет на уровне СУБД, это можно обойти. Заблокировать неизменяемые записи для записи. Ну т.е. те которые как-бы обновляются а на самом деле не обновляются. А ну хотя, здесь опять работа с транзакциями, страницы надо блокировать. Вот оно в чем дело!

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