Пользовательский интерфейс и транзакции

Возник немного комплексный вопрос: как правильно (ну или какие есть приемлемые варианты) организовать пользовательский интерфейс и использовать транзакции для отката в случае отказа пользователя сохранить изменения, в случаях ошибок? Какие ограничения в UI уместны и обоснованы? Вобщем, нужна критика и предложения. Использую Qt и PostgreSQL.

Ситуация такова.

Есть две сущности "Карточки Клиентов" (КК) и "Карточки обслуживания" (КО). Связаны между собой отношением многие-ко-многим. Иными словами - КК может иметь список, состоящий из множества "привязанных" КО. В свою очередь каждая КО может быть как индивидуальной, так и групповой, т.е. включать множество КК. В программе используется SDI.

Примерный сценарий работы:

1. Сотрудник вызывает модальный диалог "Новая КК" (Д1), заполняет основные поля
2. Переключается на вторую вкладку этого диалога "Обслуживание" - там пустая таблица
3.Сотрудник получает возможности:
3.1. выбрать из существующих обслуживаний и включить в нее создаваемого пользователя
3.2. создать новое обслуживание вызвав модальный диалог "Новое Обслуживание" Д2 и включить в него пользователя (автоматом при создании)
4.В диалоге "Новое обслуживание" или "Редактирование Обслуживания" он так же может создать или удалить КК
...
Далее цепочка может быть бесконечной - КК позволяет создавать, редактировать и удалять КО, в свою очередь при редактировании КО - можно создавать, редактировать и удалять КК.

Как собираюсь все это обрабатывать

1. Ограничения по вложенностям вводить не буду;
2. Для обеспечения откатов - перед вызовом первого диалога объявляю транзакцию, и точку отката - если очередной диалог отменен пользователем - откатываюсь до последней точки отката;
3. Глобально веду списки КК и КО, чтобы избежать повторных редактирований или удалений;
4. Веду блокировки записей КК и КО дабы избежать сюрпризов при многопользовательском доступе;
5. Перед вызовом нового диалога, данные по текущему диалогу сбрасываю в БД (иначе привязать к несохраненным данным не получиться, если не строить древовидных структур в памяти, а потом пытаться их обработать);

Как быть с обработкой возможных ошибок при работе с БД в n-ом вложенном диалоге диалоге?
Что будет с открытой транзакцией, если клиент вообще вылетит из сеанса работы с БД по какой-нибудь из причин?

Извините, что вот так сумбурно. Пока не могу все нюансы собрать воедино.

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

Цитата Akina @ 03.04.13, 19:54

Я не понимаю - кто мешает просто создавать временные сеансовые таблицы и лить туда сырые данные...

"Мешает" Бритва Оккама, принцип которым пользуюсь еще с дремучих институтских времен, и в котором уверен.

Иными словами, в моем вопросе введение манипуляций с временными таблицами должно быть обоснованно одним из:

1) Без введения временных таблиц я не смогу достичь нужного функционала/результата
2) Введение временных таблиц - существенно улучшит или оптимизирует какую-либо характеристику

Пока для меня ни 1) ни 2) - неочевидно. Более того, БД по размеру совсем скромная - записей около 100000, прирост 20-100 в сутки. Количество одновременных редактирований 15, в обозримом будущем 30-50. Существенной оптимизации, ускорения - не вижу.

Цитата Akina @ 03.04.13, 19:54

ну незачем трогать боевые таблицы!

Нет, так нельзя! Либо БД обеспечивает мне целостность данных при условии выполнения мною правильных действий, либо я ошибаюсь в своих действиях и должен их изменить на правильные, либо я ошибся в выборе "боевой" БД. О5 же - неправильность моих действий (подхода) для меня пока - неочевидны.

Цитата Akina @ 03.04.13, 19:54

тем более транзактить их, рискуя поймать отлуп у соседа

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

Так что на повестке все ж остаются три вопроса:

1) Предлагаемый мной алгоритм имеет ошибки любого характера?
2) Предлагаемый мной алгоритм оптимален или есть места для оптимизации?
3) Есть альтернативный алгоритм, другой, но более оптимальный (с любой точки зрения - реализация, исполнение)?

Цитата JoeUser @ 04.04.13, 02:39

1) Без введения временных таблиц я не смогу достичь нужного функционала/результата
2) Введение временных таблиц - существенно улучшит или оптимизирует какую-либо характеристику

Пока для меня ни 1) ни 2) - неочевидно.

Существующая (ну или описанная выше - не суть) система разрывает бизнес-логику на две части, одна остаётся на сервере, другая выносится на клиента. Можешь относиться к этому так, как считаешь нужным - но я лично считаю это весьма существенным недостатком схемы. И более чем достаточным для полного пересмотра идеологии.

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

Цитата JoeUser @ 04.04.13, 06:19

правила откатов при сохранении данных формализовать нельзя - по скольку существует "желание" пользователя.

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

Цитата Akina @ 04.04.13, 06:29

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

Нет, таких моментов в моей схеме нет - именно поэтому я и заталкиваю всю цепочку диалогов в транзакцию с локальмыми точками отката. Пользователь сможет введенное в рамках данной транзакции либо скорректировать, либо удалить. Если удалил по ошибке - ввести заново. Но ... все эти цепочки редактриований закоммитятся в базу только при закрытии последнего диалога по [Ок]. В противном случае - либо повторный проход и корректировка, либо полный роллбэк.

Но есть момент удаления - вот там откат не предусмотрен. Если он ответил на вопрос (примерно) "После удаления карточки клиента будет и удалена связанная с ней информация. Вы уверены?" - тогда все что удалил, на его совести. Восстановление только из бэкапа БД и не самостоятельно, а через админа.

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

А к чему этот вопрос?

Добавлено 04.04.13, 06:45
ЗЫ: Хотя ... удаление, если оно в цепочке диалогов - тоже откатиться, если последний диалог закрыт не по Ok.

Цитата JoeUser @ 04.04.13, 06:43

к чему этот вопрос?

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

Сообщение отредактировано: Akina - 04.04.13, 06:52

ЗЗЫ: Хотя ... вру, момент есть - это касается диалогов 1-го уровня. Если их закрыли по OK - то изменения откатить не получится, равно как и изменения, внесенные в дочерних диалогах.

Добавлено 04.04.13, 06:53

Цитата Akina @ 04.04.13, 06:49

Вот именно к тому, что как раз в моей-то схеме всё это элементарно реализуется.

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

Ну дело твоё... хочешь отслеживать завязки и всё равно натыкаться на несоответствия (вон, не сразу же вспомнил то, что в PPS потом указал) - отслеживай. Или ты правда думаешь, что окно Да-Нет-Отмена (как в любой программе при закрытии и несохранённом файле) придумали идиоты?

Более того, забыл еще сказать - есть замыкания в отношениях таблиц самих на себя. Мелочь, а геморройная чутка.

Добавлено 04.04.13, 07:03

Цитата Akina @ 04.04.13, 06:55

Или ты правда думаешь, что окно Да-Нет-Отмена (как в любой программе при закрытии и несохранённом файле) придумали идиоты?

В моем случае "Нет" думаю равносильно "Отмена".
Наша дискуссия слетает на нечто об операторе "goto". Прикладники утверждают 15 лет без goto! Системщики - а смысл?

Думаю оба варианта удобоваримы. Но просто предполагаю большую часть по манипуляции данными возложить на сам движок постгресса, кажется меньше писанины будет. Чисто ИМХО, не попробую - не узнаю.

Цитата JoeUser @ 04.04.13, 06:56

Наша дискуссия слетает на нечто об операторе "goto".

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

offtop

Цитата JoeUser @ 04.04.13, 06:56

Прикладники утверждают 15 лет без goto! Системщики - а смысл?

И те, и другие правы. И если прикладник при написании админ-скрипта в полсотни строк будет стараться избавиться от goto только для того, чтобы 15-летний аптайм не изгадить - он идиот. А админ программу того уровня, что пишут прикладники, просто не станет делать.

Добавлено 04.04.13, 07:23
Ладно.

Есть некий созданный (написанный с нуля) тобой объект. Со своими свойствами, методами, обработчиками событий и недоступными извне служебными данными.

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

Тебе нужно вызвать обработчик события. Что ты сделаешь - вызовешь его напрямую или сгенеришь вызывающее его событие?

База данных - такой же объект. И относись к нему соответственно.

PS. Отвечать на этот пост не надо, а то совсем в оффтоп уйдём. Это не аргументация, а только предложение ещё раз подумать.

Скрытый текст

Цитата Akina @ 04.04.13, 07:11

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

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

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

Добавлено 04.04.13, 07:31
В том то и дело, разочаровался я в ООП. В категории объектов заставляю себя не мыслить. Глаголо-существительное, гвозде-молоток, солдато-пистолет ... таких "натянутых за уши" объектов после популяризации ООП тьма тьмущая. Меня привлекает больше подход: модель данных + конечный автомат. И уже есть приятные новости.

Добавлено 04.04.13, 07:54
Пожалуй да, надо оффтоп закрывать. Хотя, поговорили - начали мысли систематизироваться, и это супер. Спасибо за беседу!

Akina, кстати - прокатывает на 200% ... более того, в отдельных статьях проскальзывает мнение, что именно так (как я предположил) правильно. Эт так, к слову.

Цитата JoeUser @ 15.04.13, 16:19

в отдельных статьях проскальзывает мнение, что именно так (как я предположил) правильно. Эт так, к слову.

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

Цитата Akina @ 16.04.13, 05:00

Цитата JoeUser @ 15.04.13, 16:19

в отдельных статьях проскальзывает мнение, что именно так (как я предположил) правильно. Эт так, к слову.

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

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

Цитата JoeUser @ 16.04.13, 09:43

В случае "временных таблиц" навскидку и не берусь определить алгоритм подобного.

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

Сообщение отредактировано: Akina - 16.04.13, 11:07

Пример:

* Открыта транзакция
* Пользователь создает запись N4 таблицы T1
* Пользователь блокирует запись запись N4 таблицы T1
* Пользователь блокирует запись запись N8 таблицы T2
* Пользователь модифицирует запись N8 таблицы T2

* Пользователь начал создавать запись-связку в таблице T3
... ушел курить на 30 мин
... пришел
* Пользователь записал связку в таблице T3
* Пользователь закоммитил транзакцию (или откатил)
(Во время перекура хотели удалить запись N8 таблицы T2, была заблокирована - у них не вышло. Все в шоколаде.)

Как такое можно (и нужно ли) реализовать в виде временных таблиц?

Пффф... ты, блин, читаешь, что я пишу? Всё, что ты расписываешь, включая перекур, происходит в личном временном пространстве юзера. Все остальные тупо не в курсе, что он там чёта суёт в таблицы... и только когда он всё подготовил, когда отработала процедура проверки данных (в т.ч. и на согласованность подготовленных данных и информации в основных таблицах!), он за пару миллисекунд одной транзакцией вплёвывает все подготовленные и проверенные данные во все три таблицы, с необходимыми корректировками связей. Хотел бы я видеть того умельца, который посередь этой транзакции успеет попробовать "удалить запись N8 таблицы T2"... тем более что один хрен у него ничего не выйдет.

Понятно .... т.е. ты предлагаешь:

- строить дерево проверок
- поднапрячь базу на эти проверки
- и записать одним плевком

а если проверки сфэйлились ... че делать с данными, которые пользователь набирал 3 часа?

Добавлено 16.04.13, 11:37

Цитата Akina @ 16.04.13, 11:24

Хотел бы я видеть того умельца, который посередь этой транзакции успеет попробовать "удалить запись N8 таблицы T2"... тем более что один хрен у него ничего не выйдет.

Я тот умелец
Заблокирую запись N8 таблицы T2 и пойду курить, приду и удалю.
А запустишь ты до или после моего перекура - не важно, важно что ты с моей блокировкой не разберешься и придется твой "плевок" как-то обрабатывать.

Цитата JoeUser @ 16.04.13, 11:29

а если проверки сфэйлились ... че делать с данными, которые пользователь набирал 3 часа?

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

Добавлено 16.04.13, 11:40

Цитата JoeUser @ 16.04.13, 11:29

Я тот умелец
Заблокирую запись N8 таблицы T2 и пойду курить, приду и удалю.
А запустишь ты до или после моего перекура - не важно, важно что ты с моей блокировкой не разберешься и придется твой "плевок" как-то обрабатывать.

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

Сообщение отредактировано: Akina - 16.04.13, 11:41

Цитата Akina @ 16.04.13, 11:37

Чёрта с два.
Эта запись появится лишь во время быстрой транзакции, до её начала эта запись не существует, и начать удалять тебе тупо нечего.

Цитата JoeUser @ 16.04.13, 11:19

Пример:
* Пользователь блокирует запись запись N8 таблицы T2
* Пользователь модифицирует запись N8 таблицы T2

1) Я блокирую запись N8 таблицы T2
2) Возможно удалю, возможно просто изменю, но пока блокировка висит
3) Ты редактируешь, а потом пытаешься залить одной транзакцией

Цитата JoeUser @ 16.04.13, 12:01

3) Ты редактируешь, а потом пытаешься залить одной транзакцией

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

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

Мне кажется что сложность всего тобой предлагаемого растет в разы.
А существенного улучшения нет никакого, за исключением "рассовой чистоты"

Попробую показать на еще одном примере:

Пользователь строит некое генеалогическое дерево, последовательно вызывая 378 диалоговых окон (каждое окно вызывает окно наследник и ждет его закрытия с готовыми данными, или отменой). На 78 окне ты выбрал скажем в одном из полей значение "Мuнск", ну и пошел редактировать дальше, добравшись до 378 окна.

В это время оператор увидел ошибочную запись - в слове "Мuнск" вместо "и" лат буква "u" - он удалил из справочника сей термин. Потом через час решил добавить правильный "Минск". Добавил (но Id у термина уже другой).

Пришло время сохранения твоих данных. Все диалоги успешно закрыты. Пошли твои проверки, обломились на отсутствии термина. Судя по твоему принципу ты предложишь пользователю "Ретри Аборт Игноре" ... куда 378 диалогов с набитой информацией девать - во временных таблицах, ясный перец. А как пользователю данные править, ошибки находить? 78 диалогов пробегать?

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

Цитата JoeUser @ 16.04.13, 12:28

Судя по твоему принципу ты предложишь пользователю "Ретри Аборт Игноре" ... куда 378 диалогов с набитой информацией девать - во временных таблицах, ясный перец. А как пользователю данные править, ошибки находить? 78 диалогов пробегать?

А вот тут ты не понял... пользователь получит диагностику:

У тебя в 78 окне в поле Город был введён какой-то Мuнск, такой фигни в справочнике нетути... и вот тебе на выбор варианты:
1) Щя я тебе открою поле, и ты там откорректируешь этот самый Мuнск на чёнить вменяемое;
2) Давай я тебе покажу, чё там валяется готового в справочнике (сортируя по расстоянию Левенштейна, чтобы далёко не бегать, а коли хочешь по алфавиту - сам пересотиришь), выберешь;
3) Это не ты дурак, а остальные дураки, так что впишем мы в таблицу этот город Мuнск и забубеним на него сцылочку.
Ну и стандартные 4) "Экспорт на будущее, завтра разберёмся" и 5) "Идёт оно лесом".

И в итоге: 5 пунктов ... вместо 0 пунктов

Не пять, а один из пяти. И устойчивость к любым пакостям - ответственность всё равно переваливается на оператора.

Цитата Akina @ 16.04.13, 13:08

Не пять, а один из пяти. И устойчивость к любым пакостям - ответственность всё равно переваливается на оператора.

Ну как же ... после проверки определилось, что 78 полей из-за пьяного оператора невалидны ... Надо исправлять. 78 раз.
В поем подходе - что заблокировал, то мое. Что будет потом ... да хоть трава не расти, данные внесены правильно.

Цитата JoeUser @ 16.04.13, 13:41

В поем подходе - что заблокировал, то мое. Что будет потом ... да хоть трава не расти, данные внесены правильно.

А в моём что, развен не так же?

Если заблокировал, тогда смысл последующих чеках? Блок и так обеспечивает тебе валидность.

Цитата JoeUser @ 16.04.13, 13:50

Если заблокировал, тогда смысл последующих чеках? Блок и так обеспечивает тебе валидность.

Всё очень просто.

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

Цитата Akina @ 16.04.13, 14:04

Цитата JoeUser @ 16.04.13, 13:50

Если заблокировал, тогда смысл последующих чеках? Блок и так обеспечивает тебе валидность.

Всё очень просто.

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

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

Тогда в чем соль? Блокировки без объявления транзакции ты не проведешь (говорю про PostgreSQL, тока что проверил). Поэтому на момент редактирования так же будут висеть открытые IDLE-транзакции. А поэтапный сброс данных или единовременный - не кажется ли тебе, что это аналог вопроса о том, с какой стороны правильнее намазывать бутерброд?