| Deem |
| Отправлено: 23.07.2004, 09:34 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Тут такая проблема вдруг встала:
В той самой складской программе у меня будет выписка накладных приходных, расходных, внутренних, возврата.
В их заголовки и детали входит правктически одна и та же по структуре информация. Я обрадовался, и решил все накладные запихать в две таблицы с указанием типа в заголовках. А потом меня пробило: при реализации разделения прав доступа стандартно с помощью ролей (FireBird 1.5) лица, получившие право изменять приходные накладные также могут изменять и расходные, и вобще все.
Теперь думаю, что делать? Либо хранить разные накладные в разных таблицах, либо изобретать велик для разграничения прав на уровне одной таблицы.
Можно закрыть доступ к таблице совсем, и сделать VIEW для каждого вида накладной. Это, простой способ. Можно UDF написать для контроля прав в одной таблице (но это не хочется). Или все же несколько таблиц?
Как будет "более по-взрослому" ? Переделывать пока все равно нечего. 
|
|
| Nick |
| Отправлено: 23.07.2004, 09:49 |
|
Машинист паровоза
Группа: Участник
Сообщений: 247
|
сделал в одной таблице заголовок в другой данные,
узеры и права в другой таблице,
ограничения тоступа в программе.
во первых когда делал не знал о крутых возможностях самого сервера,
во вторых Users как и другие справочники реплицируются в филиалы и нет необходимости при изменении справочника пользоватей летать по филиалам и раздавать им новые права.
в новом проекте свяжу права со справочником "Персонал"
т.к. при увольнении User а появились некоторые проблемы. |
|
| AVC |
| Отправлено: 23.07.2004, 10:18 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE |
Можно закрыть доступ к таблице совсем, и сделать VIEW для каждого вида накладной. Это, простой способ. Можно UDF написать для контроля прав в одной таблице (но это не хочется). Или все же несколько таблиц?
|
Вы сами написали пути решения. Выбор варианта зачастую зависит от возможностей сервера. Если FireBird позволяет, то решение с View предпочтительнее (это стандартное решение).
То есть:
1. Создаем закрытые таблицы залоловков и содержимого (ни у кого нет прав).
2. Создаем View'ы с дискриминацией по типу документа.
3. Создаем роли, имеющие разрешения на View'ы.
4. Назначаем пользователям роли.
Решение через SP то же имеет право на жизнь. Мне встречалась система, где весь доступ шел только через SP. Но по моему мнению с этим способом больше мороки при необходимости модификации БД.
Несколько таблиц применяется если есть проблемы с работой через View. Например в ASA6. А в остальном он ни чем не отличается от первого варианта. |
|
| olegenty |
| Отправлено: 23.07.2004, 15:05 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
я бы сделал так: на SELECT — VIEW, на INSERT/UPDATE/DELETE — SP. тем более, что FIBPlus все запросы хранит в одном компоненте. Удобно, блин.
|
|
| Deem |
| Отправлено: 26.07.2004, 13:08 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Все это хорошо, если бы не одна фигня: представление в одной таблице всех накладных еще и тем привлекло, что интерфейс работы с ними — общий. А если я растяну их по VIEW, каждый из которых мона или нельзя смотреть, как все накладные показать (или не все  ) в одной сетке? Объединять результаты запросов из нескольких вьюшек, причем выборочно, из каких. Тоже — морока.
Или придется отображать в один момент времени только накладные одного типа, причем выбор этого типа будет зависеть от прав юзера?
Вот, думаю...
|
|
| AVC |
| Отправлено: 26.07.2004, 13:40 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
А как вы хотите: что бы права ограничивались через ваше приложение или что бы пользоватедь не мог видеть неположенную информацию через любое приложение ?
|
|
| olegenty |
| Отправлено: 27.07.2004, 06:49 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
другой вариант — ХП, где по USER определяется WHERE. это очень несложно сделать, понадобится только табличка, где USER (или ROLE) будет ставиться в соответствие перечень типов накладных. но есть минус — если накладных в запросе много, то тогмоза будут хуже, чем при вьюхе или прямом селекте...
|
|
| Deem |
| Отправлено: 27.07.2004, 09:44 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
to AVC
Разграничение прав пользователя идет через роли и сервак, т.к. возможен, в любом случае, доступ к базе из другого приложения или какого-нибудь Expert или Console. Ту иного подхода быть не может.
А в приложении идет тест на возможность выполнения пользователем определенных действий, и и если — запрет, то программа не выполняет подобные запросы.
А для разграничения прав на уровне сервака без разных вьюх не обойтись. При выводе данных из нескольких аналогичных VIEW можно результат объединять по UNION :
select * from RASHOD_VIEW
union
select * from PRIHOD_VIEW
Да, я так и сделаю. И после определения прав пользователя составлять этот запрос. Тогда каждый увидит только то, что можно.
|
|
| AVC |
| Отправлено: 27.07.2004, 10:10 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Если FB позволяет, то вместо Union в данном случае выгоднее писать Union all.
Если дискриминационный признак имеет только два состояния выгоднее сделать три View или "кому доступно все" работать через базовую таблицу — Union довольно медленный оператор. |
|
| Deem |
| Отправлено: 27.07.2004, 11:50 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
To AVС
Не, не два. Это я для примера. А JOIN ALL мне на что? Это чтоб без проверки повторов записей (знаю, что если повторы есть, то обрезаются). У меня каждая накладная имеет совсем свой ID, так что повторов нет. Просто быстрее будет работать?
Просветите.
Отредактировано Deem — 27/07/2004, 12:53
|
|
| Deem |
| Отправлено: 27.07.2004, 11:56 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Да, UNION ALL есть, и штука хорошая. Т.е. как я и предполагал, он работает быстрее UNION, который ищет повторяющиеся записи. А если их точно нет, то и проверять незачем.
|
|
