Проверка логических условий при записи в БД

← →
Александр_2012 (2012-11-20 13:26) [0]

Доброго дня. Подскажите направление раскопок. Требуется организовать проверку допустимости вводимых пользователем значений. Итак, имеется основная таблица, которую заполняют пользователи. Имеется таблица-кодификатор, в которой прописаны допустимые значения для каждого поля основной таблицы. У меня на OnExit DBEdit-ов написана проверка этого соответствия и соответственно, если пользователь ввёл недопустимое значение, то получает сообщение о недопустимом значении и фокус ввода возвращается обратно. (Кстати, вариант тоже не очень удобный, т.к. при переходе с последнего редактируемого поля на DBNavigator для сохранения изменений событие OnExit не происходит, поэтому буду рад информации как можно ввести данную проверку, чтобы она отрабатывала при любых условиях). И главная проблема: есть таблица в которой прописаны логические условия типа, если в таком-то поле стоит такое-то значение, то в другом поле может быть только такое значение. Если отработать Post, то потом с помощью SQL-запросов вполне можно проверить все логические условия для основной таблицы и при обнаружении ошибки перейти в режим редактирования записи, но это плохой вариант ибо кривая запись уже сохранена. Подскажите можно ли и как, если можно провести данную проверку до отработки Post.

← →
Медвежонок Пятачок © (2012-11-20 13:34) [1]

Классно вешать такую хрень на onExit дбэдита.
Особенно когда допустимые значение одного поля зависят от значений других полей.

за такое изуверство юзеры давно уже убивают разработчиков особо жестокими способами.

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

← →
Александр_2012 (2012-11-20 13:54) [2]

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

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

Если можно расшифровать что означает "тянуть словари на клиента" и, "запросы перед попыткой сохранения" - для того, чтобы выполнить запрос к БД, значения должны быть в ней сохранены я правильно понимаю?

← →
AV © (2012-11-20 14:10) [3]

СУБД какая?

← →
Александр_2012 (2012-11-20 14:12) [4]

Oracle

← →
Плохиш © (2012-11-20 14:12) [5]

OnBeforePost

← →
AV © (2012-11-20 14:19) [6]

"тянуть словари на клиента" -с таблицы-кодификатора все значения затянуть клиенту, пусть не вводит, а выбирает

в >>OnBeforePost проверить еще раз +логику

← →
Александр_2012 (2012-11-20 14:25) [7]

> OnBeforePost

Значения полей, введённые в DBEdit-ты до отработки Post в БД ещё не внесены. Так ведь? Т.е. написать запрос типа

select count(*) from bd where not (pole between 100 and 1000)
where id=идентификатору текущей записи и, если результат=0, то ошибки нет, где (pole between 100 and 1000)-логическое условие, а not добавляется программно

к не сохраненным данным бессмысленно? Я написал утрированный запрос (такой вполне можно решить с помощью OnValidate), реально в нем присутствуют проверки на заполнение определёнными данными нескольких полей

← →
Александр_2012 (2012-11-20 14:27) [8]

> "тянуть словари на клиента" -с таблицы-кодификатора все
> значения затянуть клиенту, пусть не вводит, а выбирает

Спасибо. С этим понятно.

← →
Игорь Шевченко © (2012-11-20 14:35) [9]

> Oracle

Trigger + Raise_application_error

← →
AV © (2012-11-20 14:53) [10]

> Trigger

лучше хранимку на вставку
и закрыть от метода insert напрямую

← →
Юрий Зотов © (2012-11-20 16:07) [11]

> имеется основная таблица, которую заполняют пользователи

Вешаем на нее триггер, а в нем проверяем все, что угодно.

← →
Игорь Шевченко © (2012-11-20 18:25) [12]

AV © (20.11.12 14:53) [10]

Чем лучше ?

← →
Плохиш © (2012-11-20 18:37) [13]

> Александр_2012 (20.11.12 14:25) [7]
>
> > OnBeforePost
>
> Значения полей, введённые в DBEdit-ты до отработки Post
> в БД ещё не внесены. Так ведь? Т.е. написать запрос типа
>

Сначала внести данные, а потом проверять на корректность?
Где учат таких дерьмокодеров?

← →
AV © (2012-11-20 22:21) [14]

> Игорь Шевченко © (20.11.12 18:25) [12]

Триггер работает всегда
Допустим, вставляем много заведомо правильных данных - он работает все равно.
и про него можно забыть. Ну, бывает такое

← →
Игорь Шевченко © (2012-11-20 22:55) [15]

AV © (20.11.12 22:21) [14]

Не понял, переведи

← →
Dennis I. Komarov © (2012-11-20 23:28) [16]

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

Т.е. архитектор БД и программист GUI разные роли

← →
AV © (2012-11-20 23:42) [17]

> Игорь Шевченко © (20.11.12 22:55) [15]

Ну как, логика в триггере потом может быть забыта, потом вспомнена, потом опять забыта.
т.е. кто-то начнет писать проверки в клиенте/в БД, забыв, что там есть еще и триггер.
и ошибка в триггере обходится дорого

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

зы
Не, если грамотный триггер и программер - проблем нет, конечно

← →
AV © (2012-11-21 00:04) [18]

А вот, недавно, например
Надо вставить запись, но для этого надо выполнить сложную проверку, в том числе, с БД MSSQL, подключенной по ДБ-линку.
И сам запрос довольно сложный, методом проб выяснилось, что быстрее создавать таблицу, вытянуть в нее данные из удаленной БД, а потом уже соединять с текущей таблицей.
Как тут триггером обойтись?

← →
Игорь Шевченко © (2012-11-21 00:27) [19]

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

Феерично.

> Феерично.

:)

Запрещается:
Создание пустых сообщений, спама, преднамеренной рекламы, а так же неинформативных сообщений, типа «Здорово», «Я так и знал» или «Full Respect».

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

> под свою ответственность/гарантию
если такая нужда вообще возникает, то в правилах какая-то лажа...

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

AV © (21.11.12 09:23) [20]

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

> Игорь Шевченко © (21.11.12 09:53) [22]
> "Не стоит указывать другим участникам на несоответствие ..

Рекомендуется, не запрещается

---

> если через гуй, то почему не правами реализовано, типа -
> юзер? вставляешь по правилу ..., админ? без контроля ..

Так изначально написано, все на клиенте. один юзер БД.

> сделать "создаваемую таблицу" постоянной

можно
т.е. попробовать не дропать, а чистить. Но и тогда truncate все равно не будет работать, только delete
Таблица - снимок состояния. Он важен сейчас, а потом записи совсем не нужны. И даже вредны, если не завести еще поле(id_snapshot) ,по которому их различать.

> если такая нужда вообще возникает, то в правилах какая-то
> лажа...

ДА.
Но изначально было все не так задумано, программка 4 года назад планировалась как поделка на пару месяцев.

Я в чем согласен:
Простые правила - триггер.
Сложные - все-таки, хранимка. Оно так понятнее.
insert into TABNAME values(1, 2,3) vs InsertIntoTABNAME (1, 2,3)
во втором варианте сразу понятно, что будет еще что-то кроме insert

Могут и не

Проверка логических условий при записи в БД Найти похожие ветки