Gikerи не имею права в приложении проверять что, например, поле обязательное к заполнению заполнено не было, или имею права?
Любую здравую мысль можно довести до абсурда, и процитированное - пример его.

Подход с переносом всех проверок в СУБД в принципе имеет право на жизнь, но это пожалуй все хорошее, что о нем можно сказать. Можно утверждать, что при такой реализации невозможно сделать хорошего клиента, максимум "приемлимого". Почему: потому что логика проверки и обработки ошибок ввода существенно зависит от клиента. Например, представьте себе, что данные вводятся с помощью wizard-а - в этом случае верифицировать надо каждую очередную страницу поотдельности, в то время как вызывать ХП следовало бы по финальному OK. То есть оказывается, что серверная логика должна знать о деталях реализации клиента и учитывать их в своей реализации - это нонсенс, извращение.

Мой подход таков: большинство проверок, являясь тривиальными, должны быть реализованы и на сервере, и на клиенте. Клиент при этом обеспечивает максимально удобный интерфейс пользователя, невозможный при проверках на сервере, а серверные проверки защищают в основном от ошибок программиста - то есть ошибок в ХП и в клиенте. Сложные проверки, для реализации которых требуются изрядные усилия, делаются только на сервере.

Зависит от ситуации. Разумеется, если условия на клиенте можно скопировать с constraint-ов - нужно так делать. Но например, довольно стандартная ситуация - набор обязательных полей зависит от статуса документа. На сервере эти наборы проверяются в соответствующих ХП "изменить статус с А на Б" - а в клиенте может быть удобнее просто реализовать независимо.

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

EstetsМы пошли другим путем метаинформация о том что в данном документе, в данном состоянии такие-то поля являются редактируемыми, а такие-то доступными, хранится на сервере а проверяется на приложении.
Тут всплывает та же проблема, которую Вы описывали чуть ранее - а что если задача малость нестандартна и надо делать новую настройку. Что, если поле должно обрабатываться нестандартным компонентом-редактором. Итп.

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

Впрочем, в любом случае здесь надо смотреть по месту, универсально лучших решений не существует.

EstetsБизнес-проверки вынесены в процедуры.
Что есть бизнес-проверки?

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

EstetsА вот constraint-ов и триггеров в базе практически нет. Только в учетном блоке где проводки, чтоб ни при каких условиях не развалить баланс.
Хм. Звучит так, словно остальную базу можно разваливать :)

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

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

EstetsУ нас 90% автогенеримых процедут по поддержке общения с базой. Так что в данном контексте это удобнее.
1. Я не понимаю, как этот Ваш ответ связан со сказанным мной. Я сказал: "да, можно научить". Вы говорите: "у нас научили". Я говорю: "но по сравнению с нормальным для дельфы решением это будет менее удобно". Вы говорите: "так что удобнее".

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

Estets softwarer..... См. пример с визардом.
Не совсем согласен, приведу другой пример.
Хм. Если мы говорим об универсальной технологии, примеры, когда она работает хорошо никак не перекрывают примеров, когда она работает плохо. Она обязана либо [практически всегда] работать хорошо, либо же не будет универсальной.

EstetsПока документ находится в состоянии "редактируется", большинство его полей может быть не заполнено. Оператор может множество раз открывать его, исправлять, дозаполнять. Все бизнес-проверки начиная от "дата начала должна быть меньше даты конца" до может ли клиент уйти в минус при расчете комиссий, и разрешена ли ему короткая позиция при продаже ЦБ ;) вычисляется в момент перехода документа из состояния "редактируется" в состояние "исполнено".
И? Не очень понял, что показывает этот пример. Да, так можно делать. При этом никто не мешает сделать проверку грамотно: еще в состоянии "редактируется", если заполнены обе даты и дата начала больше - ругаться. Потому как одно дело "еще не заполнено", другое - "уже заполнено криво".

Какая разница между этими вариантами.... мне вспоминаются старые компиляторы. Когда-то работа с диалоговыми комплексами шла примерно так: написал код, запускаешь компилятор, он показывает ошибку. Запускаешь редактор, исправляешь ее, выходишь из редактора, запускаешь компилятор, он показывает следующую ошибку. Было очень неудобно. Были хорошие компиляторы - которые показывали разом несколько ошибок, если могли продолжить компиляцию, пропустив ошибочный кусок. Это здорово ускоряло процесс. А сейчас компилятор показывает некоторые ошибки прямо в ходе набора текста - и оно еще удобнее.

Estets softwarerХм. Звучит так, словно остальную базу можно разваливать :)

Ну чисто теоретически да
Тогда это пожалуй не очень интересный случай. Сродни "печатаю слепым методом. 850 знаков в минуту..."

EstetsЧасто приходилось сталкиваться, особенно при внедрении продуктов, что информация которую можно было вытащить из старых систем была неполная, и приходилось с этим мириться. Соответственно несколько полей обязательных к заполнению в новой системе в старой отсутствовали.
Это вовсе не обязано мешать проверкам целостности на сервере. Простой вариант:


В более сложном, когда подобная функциональность отсутствует - никто не мешает сделать в таблице флажок "старых данных" и создавать таблицу примерно так:

EstetsХотя на мой взглад оправданность такого подхода определяется "количеством работников занимающихся разработкой", если их 3 на проекте то возможны все подходы, если больше десяти в одной конторе то стоит задуматься, а если десятки тысяч франчайзеров, локализаторов и пр. ничего иного я не вижу. Свой язык, свое ядро, свой инструмент разработки.
Само по себе разумно, но я не вижу, каким боком тут относятся автосгенеренные процедуры. Им нет места в нормальном проекте, включая свое ядро, свой язык и свой инструмент разработки.

EstetsНет предела совершенству, но я исповедую подход минимально-необходимых проверок. На клиента такую проверку я бы все равно не вынес, в вот если бы пользователи часто ошибались именно в этом месте я бы действительно вставил проверку при сохранении документа.
Хм. То есть если бы ошибались редко, Вы этой проверки вообще бы не делали?

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

EstetsК сожалению принципы общения с БД не располагают к "интерактивно-диалоговому" режиму.
Это снова глобальное неверное утверждение.

EstetsЭто можно реализовать только "толстым" клиентом. Мне ближе по идеологии "тонкий" клиент.
Я предпочитаю смотреть с точки зрения пользователя. Ему ближе по идеологии "хорошо работающая программа" и решительно наплевать на толщину клиента. Если тонкий клиент способен работать хорошо - надо делать. Если не способен - надо его выкинуть.

EstetsА по поводу проверки всего и вся в БД, и у этого подхода есть свои подводные камни. Тут недавно всплывал пример того как человек стоял у кассы магазина и держал в руках товар, но не мог его купить, так как остаток товара в БД 0
Угу. Я об этом рассказывал.

Estetsи кассовый аппарат об этом недвухсмысленно сообщал. Жизнь к сожалению преподносит еще и не такие задачи,
Угу. Как раз в тех случаях, когда разработчики изначально схалтурили и допустили в систему кривые данные, потом начинается поиск "как теперь с ними жить". И снимаются мешающие проверки. Как раз тот случай.