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

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

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

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

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

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

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

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

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

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

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

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