Пишу информационную систему на C++ Builder + MS SQL. Двухзвенка.

Ситуация:

В базу данных необходимо сохранить документ (медицинскую выписку). Информация сохраняется в две таблицы:

1. в первую таблицу вносится 1 строка - Id_выписки (primary key), Id_пациента, Ходе_лечения, Врач, ...);
2. во вторую таблицу пишется список назначенных препаратов - Id_выписки (foreign key), Id_препарата, Дозировка, ...


При сохранении данных необходимо выполнять ряд проверок. Например, что пациент назначен хотя бы один препарат. Как это сделать?


Вижу три выхода из сложившейся ситуации:


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

2. Переписать приложение на трехзвенку и выполнять проверки подобного рода на сервере приложений.
Недостаток - отсутствие опыта реализации подобных систем.

3. Выполнять сохранение данных через хранимку, которая в качестве параметров принимает значения полей для первой таблицы + курсор для временной таблицы со списком назначаемых препаратов.
Данный пугает своей непривычностью.



Можно ли данный вопрос решить как-нибудь иначе?
И если нет, то какое из решений предпочесть при условии, что в БД понадобится реализовать еще некоторое количество таких проверок.

mcureenabА чем второй и третий варианты надёжнее первого?
Во втором случае у пользователя вообще не будет своей учетной записи на SQL-сервере.
В третьем случае у пользователя не будет доступа к таблицам напрямую. Создание / редактирование записей в таблицах возможно только через ХП.

mcureenabЯ бы предпочёл завязаться на статус документа.
Хм... интересный вариант. Т.е. пользователь пишет в обе таблицы все, что хочет, при этом остальным пользователям его "творчество" не видно до тех пор, пока он не вызывает ХП "публикации" документа, в которой и выполняются все необходимые проверки.

sqllexА почему бы не делать сохранение (хранимками, чтобы не было доступа пользователей к таблицам напрямую) в одной транзакции, управляемой с клиента? Проверка остается на клиенте.


Не устраивает тем, что проверка на клиенте. Т.е. в обход клиента с базой при таком подходе можно сделать что-нибудь нехорошее (например сохранить выписку без назначения препаратов =) ).

mcureenab mr. Garry mcureenabА чем второй и третий варианты надёжнее первого?
Во втором случае у пользователя вообще не будет своей учетной записи на SQL-сервере.
В третьем случае у пользователя не будет доступа к таблицам напрямую. Создание / редактирование записей в таблицах возможно только через ХП.


Довольно экстремальнй подход. Проблема в том, что в обеих случаях придётся дублировать функциональность уже встроенную в БД или в систему разработки - во втором случае создавать систему аутентификации, в третьем кучу CUD процедур. И то и другое не смертельно, но треубует дополнительных затрат.
Согласен.
mcureenab mr. Garry mcureenabЯ бы предпочёл завязаться на статус документа.
Хм... интересный вариант. Т.е. пользователь пишет в обе таблицы все, что хочет, при этом остальным пользователям его "творчество" не видно до тех пор, пока он не вызывает ХП "публикации" документа, в которой и выполняются все необходимые проверки.

Ну да. Ещё один +, это возможность сохранения промежуточных результатов редактирования документа.
Согласен.

mcureenabВ этом вопросе полагаться только на технические средства не очень разумно...Хм... а что Вы подразумеваете под "нетехническими" средствами?

Ошибка DBA или технический сбой конечно однозначно привести к нарушению ограничения, но мне не кажется, что отказ от реализации ее (бизнес логики) в БД решит вопросы с хитрыми ж..., сбоями в БД и косяками админов.

sqllex mr. GarryНе устраивает тем, что проверка на клиенте. Т.е. в обход клиента с базой при таком подходе можно сделать что-нибудь нехорошее (например сохранить выписку без назначения препаратов =) ).
Здрасте, я ваша тетя!
Из первого совсем не выплывает второе. Как у вас авторизация происходит и какие действия с какими объектами БД пользователю доступны?

Можно подумать, ваши пользователя все поголовно пользуются программой, которая может запускать скрипты (вызовы процедур) и все поголовно знают структуру БД и бизнес-логику.
Авторизация - встроенная в SQL сервер. Какие действия с какими объектами - долго писать. Сейчас все действия реализованы через ХП.
sqllexЯ все же хочу дождаться ответа на этот вопрос от автора топика.
mcureenab и locky в принципе обрисовали ситуацию. Цена восстановления/утери информации может оказаться выше чем стоимость разработки адекватного (надежного) интерфейса БД.

У нас есть и резервное копирование и политики безопасности, запрещающие пользователям запускать любые программы, кроме разрешенных. Только существует Access и VB, например.

sqllexЭтого чела достаточно в любом случае. Но это административная проблема, а техническая.
Не все административные проблемы можно на 100% решить административными методами =) Вот например запрет ехать на красный свет - административное решение. Однако я частенько вижу как кто-то нарушает это правило. А вот, предположим, было бы такое техническое решение, что вместо красного сигнала на дороге появлялась бы непробиваемая стена - техническое решение. Уже никто бы не ездил =))))

Ну это так... просто абстрактный пример