Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 25   вперед  Ctrl
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
То есть, как это, не обладает????
Есть еще какая-то информация, помимо той, которая "проложена" в базу?
А что с ней происходит потом?

Конечно, есть. Например, параметры и локальные переменные хранимой процедуры, внутренние переменные пакета.
26 авг 08, 15:55    [6110635]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov

pkarklin

Скажите мне, в чем принуципиальная разница в коде. Грубо:

Скорость. Первый случай не вызывает чтения данных из таблицы - только
индекс.


Гм... Это Вы о каком случие. О случие, когда есть нарушения ограничения? IF EXISTS никогда в жизни не производил чтения, а тольбко
26 авг 08, 15:57    [6110651]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
сорри, руки дрогнули,

а только поиск по индексу
26 авг 08, 15:58    [6110658]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
В моем же случае альтернативные ветки будут работать только при возникновении конкретной ошибки. Кроме того, решение с исключениями структурирование - есть четкое разделение между действительно ошибочными ситуациями (исключение), которые будут в обработчике, и штатными ветвлениями транзакции.

Приведите пример кода.
Со своей стороны, я не очень понимаю, что мжно будет сделать

try {
...
}
catch {
тут
}

если будет сгенерировано исключение.
26 авг 08, 15:59    [6110667]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
Как же не Вы предлагали?
pkarklin
На Ваше "ветвление" я уже отвечал здесь: Нужна помощь Вместо тупой отправки инструкции можно выполнить проверку.

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


Господи... Ну я же сказал, что я ничего не проверяю. Я в случие ошибки откатываю транзакцию. Проверка преподносилась как альтернатива замены обработчика ИС. Неужели это из кода не видно?
26 авг 08, 16:00    [6110675]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
То есть, как это, не обладает????
Есть еще какая-то информация, помимо той, которая "проложена" в базу?
А что с ней происходит потом?

Конечно, есть. Например, параметры и локальные переменные хранимой процедуры, внутренние переменные пакета.

Повторю вопрос: "И куда они деваются потом?".

И, кстати, откуда об этих локальных переменных и параметрах знает триггер, вызванный из другой сессии?
Или он "не считается"?
26 авг 08, 16:01    [6110681]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Dihotom
Т.е. в наборе потенциально нарушающих целостность операторов (но транзакция при этом может ветвиться) Вы каждый будете проверять даже в том случае, если ошибка маловероятна. В моем же случае альтернативные ветки будут работать только при возникновении конкретной ошибки. Кроме того, решение с исключениями структурирование - есть четкое разделение между действительно ошибочными ситуациями (исключение), которые будут в обработчике, и штатными ветвлениями транзакции.

И дополню свои слова.
В другой транзакции, имеющей такую же последовательность операторов, но другую обработку ошибок - например, при любой ошибке записать её в лог и откатить транзакцию - Вам придется повторить весь набор операторов, добавив для каждого вставку в лог (в случае ошибки). Я же воспользуюсь существующим набором (оформив его, например, в виде ХП), а в новый обработчик ошибок допишу перехват всех исключений и их логирование.
26 авг 08, 16:01    [6110685]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
В другой транзакции, имеющей такую же последовательность операторов, но другую обработку ошибок - например


Еще раз повторюсь - у меня один вариант обработки ошибок в транзакции - ее откат.
26 авг 08, 16:05    [6110697]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Господи... Ну я же сказал, что я ничего не проверяю. Я в случие ошибки откатываю транзакцию. Проверка преподносилась как альтернатива замены обработчика ИС. Неужели это из кода не видно?

Мы по кругу начали ходить.
Ситуация:
Есть транзакция. Каждый оператор транзакции потенциально может нарушить целостность БД. Вам необходимо в рамках транзакции в случае нарушения целостности выполнять альтернативный набор операторов с целью успешного завершения транзакции.
Подход 1:
При нарушении целостности транзакция откатывается. Требование к альтернативному завершению транзакции не выполнено.
Подход 2:
При нарушении целостности транзакция откатывается, но для удовлетворения требованию мы каждый оператор перед выполнением проверяем.
Подход 3:
При нарушении целостности генерируется исключение.

Плюсы и минусы подходов 2 и 3 я расписал ранее. Получилось (исходя из моих аргументов), что подход 3 явно выигрывает.
Вы это каким образом опровергаете?
26 авг 08, 16:10    [6110730]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
MasterZiv

Bogdanov Andrey wrote:

> сервер не никогда не должен откатывать транзакцию, если он ее не
> начинал.

Так, это что за принцип такой ? Где описан ?
В стандарте ? Ссылки пожалуйста давайте. А если нигде -
то это ваши выдумки, извините. Ваши личные принципы организации
ПО. Почему им все должны следовать ?


Я укажу на один источник, правда не технический.
Булгаков, М&M.
"Согласись, игемон, что перерезать волосок уж наверное может только тот, кто его подвесил" (Иешуа Га-Ноцри)
26 авг 08, 16:13    [6110752]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Приведите пример кода.
Со своей стороны, я не очень понимаю, что мжно будет сделать

try {
...
}
catch {
тут
}

если будет сгенерировано исключение.

Вам на C++ пример или на Java? :)
int i = 2;

try
{
    some_func(); // типа наш триггер, в котором возникает исключение - ни о каком i он не знает
}
catch (...)
{
    if (i % 2 = 0)
    {
        // все хорошо, транзакцию завершаем
    }
    else
    {
        // все плохо, транзакцию откатываем
    }
}
26 авг 08, 16:14    [6110759]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Повторю вопрос: "И куда они деваются потом?".

И, кстати, откуда об этих локальных переменных и параметрах знает триггер, вызванный из другой сессии?
Или он "не считается"?

Честно говоря, я не понимаю этого вопроса. Когда потом? Нужно рассказать, как память в стеке освобождается?
Что касается знаний триггера - так я о том и говорю, триггер о них ничего не знает. Поэтом не может принять решение о том, как именно ему обрабатывать ошибку. В зависимости от параметра, пришедшего в ХП, начинающую транзакцию, мы можем как откатить её, так и пустить по альтернативному пути при нарушении целостности одним и операторов.
26 авг 08, 16:18    [6110791]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
Плюсы и минусы подходов 2 и 3 я расписал ранее. Получилось (исходя из моих аргументов), что подход 3 явно выигрывает.
Вы это каким образом опровергаете?


Интересно, что я должен опровергнуть и почему во втором варианте у Вас транзакция откатывается?! Вы придумываете ситуацию, которая изначально не обсуждалась. Если постановка задачи будет именно в таком виде:

Dihotom
в случае нарушения целостности выполнять альтернативный набор операторов с целью успешного завершения транзакции.


Никто в здравом уме не будет делать триггер с ROLLBACK.
26 авг 08, 16:19    [6110802]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Приведите пример кода.
Со своей стороны, я не очень понимаю, что мжно будет сделать

try {
...
}
catch {
тут
}

если будет сгенерировано исключение.

Вам на C++ пример или на Java? :)
int i = 2;

try
{
    some_func(); // типа наш триггер, в котором возникает исключение - ни о каком i он не знает
}
catch (...)
{
    if (i % 2 = 0)
    {
        // все хорошо, транзакцию завершаем
    }
    else
    {
        // все плохо, транзакцию откатываем
    }
}


Ну, ничего чудесного я не увидел.
Теперь вопрос - как из "все плохо" вы сделаете что-то для возможной починки и успешного альтернативного завершения транзакции? Если весь код по этому завершению лежит внутри try {}?
26 авг 08, 16:19    [6110807]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Повторю вопрос: "И куда они деваются потом?".

И, кстати, откуда об этих локальных переменных и параметрах знает триггер, вызванный из другой сессии?
Или он "не считается"?

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


Нет. Нужно рассказать, почему, при одной и той же исходной ситуации в базе данных, итоговое состояние базы может оказаться разным. В зависимости от данных на клиенте, которые потом в базу не сохраняются.
26 авг 08, 16:22    [6110836]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

pkarklin
а только поиск по индексу

....который усуществляется без его (индекса) чтения. Мои поздравления MS
- ей удалось создать СУБД со встроенным телепатором.

Разберём случай, когда надо выполнить INSERT OR UPDATE, но уже первый
INSERT успешен:
1) С использованием обработчика исключения: буфер данных записывается,
индекс читается, модифицируется, записывается. 4 операции
2) С использованием exists: индекс читается, буфер данных записывается,
индекс читается, модифицируется, записывается. 5 операций.

Posted via ActualForum NNTP Server 1.4

26 авг 08, 16:25    [6110851]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Dihotom
Плюсы и минусы подходов 2 и 3 я расписал ранее. Получилось (исходя из моих аргументов), что подход 3 явно выигрывает.
Вы это каким образом опровергаете?


Интересно, что я должен опровергнуть и почему во втором варианте у Вас транзакция откатывается?! Вы придумываете ситуацию, которая изначально не обсуждалась. Если постановка задачи будет именно в таком виде:

Dihotom
в случае нарушения целостности выполнять альтернативный набор операторов с целью успешного завершения транзакции.


Никто в здравом уме не будет делать триггер с ROLLBACK.

Так изменчивость требований - это один из основных факторов, приводящих к изменениям в информационных системах. Я пытаюсь доказать, что вариант с откатом в триггере немасштабируемый, что завершение транзакции в слое, отличном от слоя, который эту транзакцию начал - тоже немасштабируемый. Это всё равно что в C выделять память на одном уровне функций, а освобождать - на другом: можно, разрешено, по человеку, вносящему изменения в этот код не позавидуешь.

Если же мы обсуждаем мелкие или наколенные разработки, то никаких вопросов нет - все пишут как хочется, как удобнее, как быстрее и т.п.. Речь еще в начале темы велась о концепции, что предполагает решения, заточенные на перспективу.

P.S.: Не знаю, может, я не совсем правильно термин масштабируемость употребил. Наверно, правильнее было сказать "поддерживаемость и сопровождаемость".
26 авг 08, 16:28    [6110884]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov

....который усуществляется без его (индекса) чтения. Мои поздравления MS
- ей удалось создать СУБД со встроенным телепатором.


При отсутвии записи. В случие:

BEGIN TRY
 INSERT T1 VALUES(1)
END TRY
BEGIN CATCH
  UPDATE T1 SET col1 = 2 WHERE col1 = 1
END  CATCH
GO

Table 'T1'. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

В случие:


IF EXISTS(SELECT * FROM T1 WHERE col1 = 1) 
  UPDATE T1 SET col1 = 2 WHERE col1 = 2
ELSE
  INSERT T1(col1) VALUES(1) 


Table 'T1'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'T1'. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Где Вы так нацчились считать?!
26 авг 08, 16:33    [6110928]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Нет. Нужно рассказать, почему, при одной и той же исходной ситуации в базе данных, итоговое состояние базы может оказаться разным. В зависимости от данных на клиенте, которые потом в базу не сохраняются.

А что в этом такого? Возьмем тот же измученный платежный документ, приводящий к красному сальдо на счете. В случае, если возникает красное сальдо, система запрашивает у клиента... хм... пароль. Если пароль тестерский, то документ заносится в базу, но помечается как непроведенный. Если пароль админский, то документ проводится на сумму остатка на счете. В противном случае (пароль не задан или указан неверно) - транзакция откатывается.
Поэтому ответ на вопрос "почему" - потому что так нужно бизнесу.
26 авг 08, 16:34    [6110938]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
pkarklin
Dihotom
Плюсы и минусы подходов 2 и 3 я расписал ранее. Получилось (исходя из моих аргументов), что подход 3 явно выигрывает.
Вы это каким образом опровергаете?


Интересно, что я должен опровергнуть и почему во втором варианте у Вас транзакция откатывается?! Вы придумываете ситуацию, которая изначально не обсуждалась. Если постановка задачи будет именно в таком виде:

Dihotom
в случае нарушения целостности выполнять альтернативный набор операторов с целью успешного завершения транзакции.


Никто в здравом уме не будет делать триггер с ROLLBACK.

Так изменчивость требований - это один из основных факторов, приводящих к изменениям в информационных системах. Я пытаюсь доказать, что вариант с откатом в триггере немасштабируемый, что завершение транзакции в слое, отличном от слоя, который эту транзакцию начал - тоже немасштабируемый. Это всё равно что в C выделять память на одном уровне функций, а освобождать - на другом: можно, разрешено, по человеку, вносящему изменения в этот код не позавидуешь.

Если же мы обсуждаем мелкие или наколенные разработки, то никаких вопросов нет - все пишут как хочется, как удобнее, как быстрее и т.п.. Речь еще в начале темы велась о концепции, что предполагает решения, заточенные на перспективу.

P.S.: Не знаю, может, я не совсем правильно термин масштабируемость употребил. Наверно, правильнее было сказать "поддерживаемость и сопровождаемость".

Если посмотреть на начало, то можно как раз увидеть, что основной тезис был "откат транзакции в триггере" - зло.
Сейчас обсуждается совсем другое утверждение - "пусть триггер не отработал, я сам решу что делать дальше". И я (и не только я) утверждаю, что такой подход - зло. Триггер должен сделать все, что он может, для успешного завершения транзакции, и, если триггер "не смог", то это необходимое и достаточное условие для отката транзакции.
26 авг 08, 16:34    [6110940]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Нет. Нужно рассказать, почему, при одной и той же исходной ситуации в базе данных, итоговое состояние базы может оказаться разным. В зависимости от данных на клиенте, которые потом в базу не сохраняются.

А что в этом такого? Возьмем тот же измученный платежный документ, приводящий к красному сальдо на счете. В случае, если возникает красное сальдо, система запрашивает у клиента... хм... пароль. Если пароль тестерский, то документ заносится в базу, но помечается как непроведенный. Если пароль админский, то документ проводится на сумму остатка на счете. В противном случае (пароль не задан или указан неверно) - транзакция откатывается.
Поэтому ответ на вопрос "почему" - потому что так нужно бизнесу.


Вообще-то, пользователь, вводящий документ, уже авторизован, потому как пароль он вводил при входе в базу/приложение. Соответсвенно, ссылка на этого пользователя должна быть обязательно схоранена в базе, что бы потом было известно, кому должно стать "мучительно больно". А из этого следует, что вся необходимая информация в триггере у нас есть.
Если Ваша система постоена по-другому - мои соболезнования.

Как говорил мой незабвенный преподаватель математики "Идитя и учитя!".

ЗЫ. А уж пользователь вводящий пароль в открытой транзакции - песнь песней. А если он в это время покурить пойдет?

ЗЫ2. Сдавайтесь, пока еще больших глупостей не наговорили.
26 авг 08, 16:40    [6110989]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Триггер должен сделать все, что он может, для успешного завершения транзакции

Вот с этим я согласен. Только триггер понятия не имеет в рамках какой транзакции он работает, поэтому сделать он может не так много.

Николай1
и, если триггер "не смог", то это необходимое и достаточное условие для отката транзакции.

А вот с этим категорически не согласен. И этот подход, действительно, считаю злом. Почему - уже объяснил.
26 авг 08, 16:41    [6111000]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

pkarklin

Table 'T1'. Scan count 0, logical reads 0, physical reads 0, read-ahead
reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Насколько я понимаю, эта строчка относится к запросу внутри exists. Я
уже поздравлял инженеров MS, сумевших выполнить этот запрос
телепатически, ничего не читая.

Posted via ActualForum NNTP Server 1.4

26 авг 08, 16:43    [6111019]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Вообще-то, пользователь, вводящий документ, уже авторизован, потому как пароль он вводил при входе в базу/приложение. Соответсвенно, ссылка на этого пользователя должна быть обязательно схоранена в базе, что бы потом было известно, кому должно стать "мучительно больно". А из этого следует, что вся необходимая информация в триггере у нас есть.
Если Ваша система постоена по-другому - мои соболезнования.

Как говорил мой незабвенный преподаватель математики "Идитя и учитя!".

ЗЫ. А уж пользователь вводящий пароль в открытой транзакции - песнь песней. А если он в это время покурить пойдет?

ЗЫ2. Сдавайтесь, пока еще больших глупостей не наговорили.

Я бы посоветовал смотреть на примеры несколько шире. И пользователя, и его пароль не нужно воспринимать буквально. Смысл в том, что пользователь может настроить (и не хранить его в БД) поведение системы в случае возникновения сбоя.

P.S.: Странно, почему Вы не придрались к проведению админом документа на сумму остатка ;)
26 авг 08, 16:46    [6111049]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Триггер должен сделать все, что он может, для успешного завершения транзакции

Вот с этим я согласен. Только триггер понятия не имеет в рамках какой транзакции он работает, поэтому сделать он может не так много.

Николай1
и, если триггер "не смог", то это необходимое и достаточное условие для отката транзакции.

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


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

ЗЫ. Можно вспомнить, например, о deffefed и nodeffered, если я ничего не напутал.

Пример _рабочего_ кода, с вызовом альтернативного пути выполненения транзакции я так и не увидел. Рекурсивный try {} catch {} как-то не впечатляет.
26 авг 08, 16:52    [6111103]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить