|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Oleg Bokanov 2:5020/400 28 Apr 2002 15:57:50
To : Serguei Tarassov
Subject : Re: Принцип 4-х глаз
--------------------------------------------------------------------------------
"Serguei Tarassov" <templar@arbinada.com> сообщил/сообщила в новостях
следующее: news:aaf02m$na6$2@host.talk.ru...
> Дорогой наш товарищ Oleg
> Hа запрос в комитет fido7.su.dbms от 27 апреля 2002 года, отправленного
тов.
> Oleg Bokanov к тов. со всей партийной прямотой отвечаем:
>
> OB> Есть необходимость реализовать в системе принцип 4-х глаз. То есть
> OB> смысл сводится к тому, что никакие изменения в базе не являются
> OB> актуальными пока не будут подтверждены кем-то. Как-то у меня слабо
> OB> укладывается такой подход в привычную модель. Если у кого-нибудь
> OB> есть опыт реализации такого подхода или просто соображения на эту
> OB> тему, буду рад выслушать.
> В твое хорошо сформулированном вопросе уже есть половина ответа :-)
> Для каждого "глаза" сделай свою VIEW - она будет неизменной. А
организовать
> "подписи" внутри на уровне таблиц внутри по-разному, в том числе. потом по
> ходу дела реализацию изменить. Hапример, "Документы" - 1:М - "Подписи", а
во
> вьюшку "Действующие документы" попадают только те, у которых count(*)
> подписей = нужному числу ответственных лиц. В MSSQL 2000 на эту вьюшку
можно
> навесить instead of триггеры и тогда можно работать с ней, как с
таблицей -
> такой прием лично мне нравится: просто и со вкусом. Можно в данном случае
> отбиться и хр.процедурами, но это посложнее (особенно на клиенте с
> интеллектуальным датасетом типа ADO/DBExpress, который по умолчанию сам
> решает, как обновлять данные) и ИМХО менее красиво.
>
>
> --
> с коминтерновским приветом участникам съезда
> тов. Сергей (Тарасов)
> mailto:serge@arbinada.com
>
Со view и т.п. все более-менее понятно. Кстати, платформа - Oracle, так что
возможностей хватит. Меня беспокоит немного другой вопрос - при реализации
"принципа 4-х глаз" очевидно подразумевается, что неверифицированные данные
должны быть "не видны" при большинстве действий и, кроме того, могут быть и
неверифицированы, т.е. потребуется откат. Следовательно, необходимо как-то
хранить и "действующие" и "новые" данные. Hу и разумеется аналогичные
"тонкости" существуют при удалении. Фактически, существует две возможности -
хранение в одной таблице или в разных. И в том и в другом случае возникают
определенные трудности в отношении ограничений целостности - и первичные и
внешние ключи. Если хранить действующие и новые в одной таблице, то
несколько меняется подход к первичному ключу, да и внешние ключи при этом
должны будут включать признак "верификации" очевидно. Hу и так далее...
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
