Спасибо

Ребят, подскажите где почитать по теме:
пришлось делать проект в котором идёт обработка заказов. У каждого заказа несколько атрибутов разрешающих или запрещающих его редактировать/удалять и ещё несколько.. так же есть 4 режима от которых зависят некоторые настройки записи в базу. Всё это хранится в таблицах. И чтобы записать в базу какое-то значение по заказу приходится делать кучу проверок с объединением нескольких таблиц.
Получается громадный запрос с тучей подзапросов и различных условных операторов.
Выглядит монструозно, с полпинка и не разобраться что к чему в нем. Начал сомневаться, что все правильно делаю.
Какие "best practices" так сказать тут?
Гуглил по всякому, но безрезультатно

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

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

Я думал обработку атрибутов делать на клиенте, но это, вроде как небезопасно. Прав ли я или все же переложить часть работы на клиент?
Просто, например, тот же атрибут запрета редактирования изменяется руками на клиенте и в базу записывается не разрешенное значение

На клиенте я бы не стал

слушайте, а как можно определить причину аттеншна, если в TextData пусто? pytds генерит с частотой десяток аттеншнов в секунду, при этом в самом pytds ошибок не выскакивает, запросы (которые вызывают аттеншны) выполняются оч быстро (не похоже на аттеншн по таймауту), данные возвращают (не похоже на аттеншн по отмене запроса)

Тут интересный вопрос :как сделать, чтобы uncommited не смогло прочитать незаконченные изменения?

Может перейти на снапшот изоляцию

Почему-то она не ставится, может там надо что-то разрешить юзеру?

Там
Alter database abc set read... on
Не работают

Не понятно, в чём проблема...
Тебе запрос не написать?

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

покажи...

С тела я его час писать буду)))
+ "ТЗ" расписывать надо
Описал проблему "в двух словах", думал понятно в общих чертах

В общих чертах понятно.
У тебя - общая проблема.

Ну сделай вюхи  тай селект с них

Или процедурами атрибуты проверяй

Хых...
Я оч рад помощи, спасибо
Но прост реально такое в чат вываливать, подумал ссаными тряпками погонят.
Завтра у компа буду, напишу