Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Александр_2012 © (2012-11-20 13:26:00)
Доброго дня. Подскажите направление раскопок. Требуется организовать проверку допустимости вводимых пользователем значений. Итак, имеется основная таблица, которую заполняют пользователи. Имеется таблица-кодификатор, в которой прописаны допустимые значения для каждого поля основной таблицы. У меня на OnExit DBEdit-ов написана проверка этого соответствия и соответственно, если пользователь ввёл недопустимое значение, то получает сообщение о недопустимом значении и фокус ввода возвращается обратно. (Кстати, вариант тоже не очень удобный, т.к. при переходе с последнего редактируемого поля на DBNavigator для сохранения изменений событие OnExit не происходит, поэтому буду рад информации как можно ввести данную проверку, чтобы она отрабатывала при любых условиях). И главная проблема: есть таблица в которой прописаны логические условия типа, если в таком-то поле стоит такое-то значение, то в другом поле может быть только такое значение. Если отработать Post, то потом с помощью SQL-запросов вполне можно проверить все логические условия для основной таблицы и при обнаружении ошибки перейти в режим редактирования записи, но это плохой вариант ибо кривая запись уже сохранена. Подскажите можно ли и как, если можно провести данную проверку до отработки Post.

anatoly podgoretsky (2012-11-21 13:19:00) [1]
Могут и не

AV (2012-11-21 10:47:00) [2]

> anatoly podgoretsky © (21.11.12 10:41) [24]

Мои посты - можно :)
тему не надо, не моя.

Игорь Шевченко (2012-11-21 10:46:00) [3]
AV © (21.11.12 10:23) [23]

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

anatoly podgoretsky (2012-11-21 10:41:00) [4]

> AV © (21.11.12 10:23) [23]

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

AV (2012-11-21 10:23:00) [5]

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

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

---

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

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

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

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

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

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

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

Игорь Шевченко (2012-11-21 09:53:00) [6]
AV © (21.11.12 09:23) [20]

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

sniknik (2012-11-21 09:47:00) [7]
> юзеры через гуй могут
если через гуй, то почему не правами реализовано, типа - юзер? вставляешь по правилу ..., админ? без контроля ...

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

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

AV (2012-11-21 09:23:00) [8]

> Феерично.

:)

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

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

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

Феерично.

AV (2012-11-21 00:04:00) [10]
А вот, недавно, например
Надо вставить запись, но для этого надо выполнить сложную проверку, в том числе, с БД MSSQL, подключенной по ДБ-линку.
И сам запрос довольно сложный, методом проб выяснилось, что быстрее создавать таблицу, вытянуть в нее данные из удаленной БД, а потом уже соединять с текущей таблицей.
Как тут триггером обойтись?

AV (2012-11-20 23:42:00) [11]

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

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

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

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

Dennis I. Komarov (2012-11-20 23:28:00) [12]
делить GUI и логику БД
юзверь знать не знает о таблицах и пр. ерунде. у него есть форма ввода, куда он вводит данные. логика ввода данных осуществляется методами GUI, не исключая при этом обращения к БД.
При вводе - хранимка, куда передаются введеные данные и корректность их уже проверяется средствами БД.

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

Игорь Шевченко (2012-11-20 22:55:00) [13]
AV © (20.11.12 22:21) [14]

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

AV (2012-11-20 22:21:00) [14]

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

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

Плохиш (2012-11-20 18:37:00) [15]

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

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

Игорь Шевченко (2012-11-20 18:25:00) [16]
AV © (20.11.12 14:53) [10]

Чем лучше?

Юрий Зотов (2012-11-20 16:07:00) [17]
> имеется основная таблица, которую заполняют пользователи

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

AV (2012-11-20 14:53:00) [18]

> Trigger

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

Игорь Шевченко (2012-11-20 14:35:00) [19]

> Oracle

Trigger + Raise_application_error

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

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »