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

Возник немного комплексный вопрос: как правильно (ну или какие есть приемлемые варианты) организовать пользовательский интерфейс и использовать транзакции для отката в случае отказа пользователя сохранить изменения, в случаях ошибок? Какие ограничения в 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

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

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