Alexey KudinovКак результат отсутствия своевременного обновления новые "правильные" клиенты могут в своей работе использовать данные введенные "неправильными" и наоборот.
Могут. В результате этого может потребоваться выгонять пользователей и синхронно менять. Но далеко не "обязано потребоваться".

Alexey KudinovВ данном случае не суть важно, меняются ли правила игры посередине транзакции или посередине одновременной работы различных пользователей с одними данными. Бардак будет и в том и в ином случае.
Хм. Я вижу, что Вы действительно не понимаете, о чем я, и тянете в другую сторону. Попробую привести пример.

Представьте себе, что есть ХП, которая просто возвращает константу 2000. Есть бизнес-функция, которая дважды вызывает эту ХП, складывает полученные результаты и записывает в таблицу. Вдруг выяснилось, что это ошибка, и на самом деле ХП должна возвращать число 20. Мы меняем ХП, а для корректировки данных выполняем скрипт


Обратите внимание: этот скрипт необязательно запускать тут же; он вполне правильно отработает, если выполнить его позже, скажем ночью. Можно, конечно, выполнить и вместе с накатом процедуры.

Проблема этой ситуации в том, что возможен вариант, когда первый вызов ХП вернет значение 2000, второй - значение 20, и в таблицу угодит value = 2020. После этого любой из вышеназванных вариантов покалечит данные; вместо исправленной БД мы получим разрушенную. Возможен и другой вариант: первый вызов вернул 2000, прошел накат процедуры и апдейт данных, второй вызов вернул 20, значение 2020 попало в таблицу и уже корректироваться не будет; опять же, база разрушена. При "клиентском" решении такой проблемы возникнуть не может, ее можно разве что специально создать.

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

Alexey KudinovЗамечу еще, что растянутость процесса обновления во втором случае способствует бОльшей рассогласованности данных.
Зависит от. Вы до сих пор игнорируете мои примеры, но все же еще раз призову взглянуть в отчет по дебиторке; если какие-то активные действия по нему предпринимаются раз в месяц, то затягивание рассогласованности очевидно решительно пофиг - главное, успеть все скорректировать к моменту X, не более того.

aagНу а если, например, правила игры меняются не внутри серверной транзакции, но посреди бизнес-операции?
Во-первых, чем ближе эти понятия - тем лучше. Любое расхождение между ними является перманентным источником проблем.

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

aagЦелостность данных - да, формально нарушена может быть не будет. А вот логически - с точки зрения бизнеса - ошибки могут быть точно такие же.
Данные либо целостны, либо нет, либо корректны, либо нет. При втором ответе их надо исправлять, это отдельный сложный процесс. Что такое "целостные данные с логическими ошибками" я не понимаю.

aagОтсутствие транзакции просто переводит проблему на другой уровень.
Я не понимаю, что за "отсутствие транзакции" и откуда оно взялось.

aagА как же
авторЛично я не люблю решать административно задачи, легко решающиеся технически
Согласуется. Целиком технически эта задача легко не решается. А вот если подкрепить техническими решениями решение управленческое - решается легко. Этот вариант мне и нравится.

aagВедь тут вы практически полагаетесь на разумность и аккуратность пользователя, причем в таком случае, когда этого делать никак не следует. У пользователя, как правило, полным-полно своих забот и заставлять его самого следить за версиями ПО - не очень хорошая практика.
Хм. У меня такое впечатление, что Вы не прочитали абзац, на который отвечаете. Если, по-Вашему, прыгающий в лицо баннер "Сменилась версия. Обновитесь как только закончите текущую бизнес-операцию" - это "самом следить за версиями", я просто не знаю, что и думать.

aagЯ лично считаю, что данная проблема целиком и полностью относится к процессу внедрения версии; если существует вероятность непредсказуемых изменений данных и пр., следует заранее согласовывать время и порядок внедрения измнений - хоть сервенрных, хоть клиентских, без разницы.
Это легко, когда внедрение версии идет раз-два в год. А когда патчи накатываются по пять раз в день, подход становится малость неудобным.

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

Фразы aag-а, я к сожалению пока просто не понимаю.

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

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

В-третьих, мне кажется, последний раз я отвечал на этот вопрос в примере с возвратом 2000 и 20, который, по Вашим словам, Вы прекрасно поняли. Боюсь, мне нечего больше сказать, разве что переформулировать и сказать другими словами то же, что и раньше. На всякий случай еще раз:

я привел пример, который в "клиентской" реализации, то есть в той же дебеторке, вернет число либо 40, либо 4000, а в ХП-реализации может вернуть 40, 4000 либо 2020. Именно наличие этого третьего варианта усложняет ситуацию в случае ХП. Все. Не знаю что еще и как еще могу сказать. Если не объяснил - значит, так бездарно объясняю.

Alexey KudinovПожалуйста ответьте на вопрос: есть хранимая процедура, которая возвращает отчет по деб. задолженности. Она не используется в транзакции два и более раз.
Нужно ли для ее обновления выгонять пользователей из БД ?
Мне кажется, я ответил на этот вопрос еще на предыдущей странице. Если эта ХП всегда является единственной в транзакции, в этом и только в этом случае ее можно обновлять без обрезания пользователей. Для клиентской организации такого ограничения не требуется; cуществуют ситуации, когда запрос выполняется несколько раз в одной транзакции, и тем не менее патч может быть проведен по ходу обычной работы.

Alexey Kudinov Да где же эта "безусловная проблема, существующая при любых условиях" ? Вы можете ее сформулировать ?
Неоднократно. Проблема 2000/20.

Alexey KudinovВы предлагаете считать частный случай многократного вызова одной ХП
Что я предлагаю считать, я написал пару страниц назад; это - простой пример.

Имея текст некоего патча, список изменяемых им ХП или нет, в общем случае мы не можем с приемлимыми трудозатратами вычислить, проявится ли указанная проблема или нет. Поэтому нам придется либо очень жестко ограничиться архитектурно (одна транзакция - одна ХП), либо, как я упоминал раньше, просить знатока системы дать зуб, либо наконец надеяться на "авось не бахнет". Либо выгонять пользователей. Первый и третий варианты с моей точки зрения недопустимы, второй - допустим только для небольших решений, которые действительно один человек может досконально знать. Согласен, мне стоило сказать "безусловно, за исключением варианта #2".

Alexey Kudinovну вот, уже появился патч
Патч появился в тот момент, когда я назвал в минусах процедурного подхода накат тривиального патча. С тех пор мы его обсуждаем; эту фразу Вы только что процитировали. Я не очень понял слово "уже" в таком контексте.

Alexey Kudinov+ предположение, что те, кто его составляют не знают как используются обновляемые ХП
Вы снова очень существенно изменили использованную мной формулировку.

Это не предположение, а факт для системы заметных размеров и несупержесткой архитектуры. Еще тридцать лет назад, когда всерьез задумались о тестировании, начали с постулата "невозможно накрыть тестами абсолютно все варианты взаимодействия, все логические цепочки и взаимосвязи". За прошедшее время ситуация скорее ухудшилась.

Alexey Kudinov+ еще одно предположение что поэтому в архитектуре решат зашить 1 процедура = 1 транзакция.
И снова Вы вроде как пересказываете мои слова, а получается нечто совершенно другое.

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

Alexey KudinovВам не кажется, что для такого безапиляционного утверждения
Не придавайте слишком большого значения, но "апелляция".

Alexey Kudinovслишком много предположений
Пока не увидел ни одного, действительно высказанного мной.

Alexey Kudinovкоторые в добавок не имеют прямого отношения к собственно процедурному подходу ?
На тему связи моего утверждения с процедурным подходом я исписал уже около двух страниц форума. Поскольку предположений пока не обнаружено, о их связи с процедурным подходом говорить не готов, да и незачем собственно.

Alexey KudinovOFF: замечу, что идея "одна транзакция - одна ХП" не так глупа как кажется на первый взгляд, но в данном топике это не важно.
Ее глупость или не глупость действительно не важна. Это архитектура с исключительно жесткими ограничениями, соответственно применимая только в относительно редких особых случаях. Поэтому я упомянул ее как исключение и далее в основном говорил об "общем случае за этим исключением".

Alexey KudinovВы говорите что то, что присылающий обновление ХП не знает где она используется
Это утверждение ложно. Мне сейчас очень хочется спать, но тем не менее я крайне удивлюсь, если Вы найдете в моих фразах такую цитату.

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

Alexey KudinovСудя по всему принципиальная разница в наших с вами взглядах в вероятностных оценках и степени риска порчи данных в первом и втором варианте.
К сожалению, Вы так и не обратили внимание, что я не говорю о вероятностных оценках и избегаю их там, где речь идет о сохранности данных. Я говорю о простой дискретной системе: "есть гарантия сохранности" / "нет гарантии сохранности". И в зависимости от этого ответа допускаю либо не допускаю обновление по живому.

Alexey KudinovУдивляйтесь:
Тому, что Вы заботливо вырезали стоящую перед этим фразу "Вы снова очень существенно изменили использованную мной формулировку"? Я просил Вас показать мои слова, а не Ваши собственные.

Alexey KudinovИли вы опять скажете, что я не так трактовал ваши слова ?
Скажу, что помимо прочего, даже два процитированных Вами Ваших же утверждения различны по смыслу, на что я готов вторично обратить Ваше внимание. Если, конечно, Вы не считаете слова "где" и "как" синонимами.