|
|
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
Начинаю проектировать базу, и вот решил совета спросить, как лучше. Смысл такой. Производство продукции. На каждом этапе контроль качества. Если какие-либо отклонения - вносится в некую таблицу - HEADTable (кем занесено, дата, какая продукция, количество, описание несоответствия). Вторая таблица - подчиненная - DetailTable . В ней различные уполномоченные отделы производят свои отметки (заключение, метод устранения, даты). Таких служб (уполномоченных отделов) несколько (служба контроля качества, цех производства, склад сырья, цех упаковки продукции). Видится каждой службе присвоить свой ID и хранить в виде справочника - BookTable . Когда заинтересованные службы проставят свои отметки, выносится решение о судьбе бракованной продукции (в HEADTable ) и там проставляет крыжик - все, с этого момента редактировать эту запись нельзя. В системе Windows-авторизация. Предлагается создать несколько групп, так как службы не должны редактировать сам документ или запись другой службы. Тот, кто заводит документ, не может редактировать записи служб; тот, кто закрывает документ, так же не может править этот документ и записи служб. В самом приложении хочу по умолчанию всем показывать все возможности работы с документом, но при попытке, например одной служб создать новый документ или закрыть открытый производить проверку на принадлежность группе (можно, например, проверить имеет ли он право редактировать такую-то таблицу) и если прав нет, выдать сообщение: "Извините, но данная операция недоступна". Как это сделать в пользовательском приложении? С разграничением прав особо не работал, поэтому интересны любые мысли относительно сказанного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 11:59 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
С этим "В самом приложении хочу по умолчанию всем показывать все возможности работы с документом" вообще проблем нет. Делайте stored procedures и раздавайте на них разные права разным группам пользователей. Обычно хотят, чтобы возможности были даже не видны тем, кому не положено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 12:03 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
защиту от несанкционированного изменения лучше делать не в клиентском приложении а в триггере таблицы проверка прав и если не админ и не уполномочен - откат иначе найдутся умники которые подключатся к базе не из твоего приложения и отредактируют таблицы вручную если все таки решишь на клиенте то в VB это выглядит примерно так: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 12:10 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
MsDatabaseruзащиту от несанкционированного изменения лучше делать не в клиентском приложении а в триггере таблицы проверка прав и если не админ и не уполномочен - откат иначе найдутся умники которые подключатся к базе не из твоего приложения и отредактируют таблицы вручную Да, физическое редактирование базы разумеется будет контролироваться триггерами таблиц. Я имею в виду в клиентском приложении не защиту, а больше информирование. Скажем на панели инструментов есть кнопки со всеми функциями. При нажатии на кнопку для редактирования конечно же будет своя некая форма. Так проверка пользователя должна пройти до вызова этой формы, а не потом, когда он туда что-то введет, сохранит, а триггер откатит его изменения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 12:23 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
Я делаю так Есть таблица пользователей и групп Есть таблиза операций Есть таблиза прав на выполнение отдельных операций Пишется процедура которая на входе имеет кто и что хочет сделать На выходе или Ок или объяснения почему нельзя (можно без объяснений если лениво) Права на все таблицы только по чтению, чтобы не заморачиваться с тригерами все изменения данных через процедуры, в процедурах первым образом проверяем права через вышеописанную процедуру. В клиентской части также при нажатии на любую кнопку, попытку выполнить любое действие вызываем процедуру проверки прав и в зависимости от результата даем или нет делать что просит пользователь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 12:47 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
nnovЯ делаю так... Я так же делал, когда базы на InterBase делал. В MS SQL хочется использовать весь тот арсенал средств, чем богата СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 13:03 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
nervЯ так же делал, когда базы на InterBase делал. В MS SQL хочется использовать весь тот арсенал средств, чем богата СУБД. Не вижу принцииальной разницы, если разделять доступ на уровне, бизнес операций, все равно самому надо реализовывать логику, никакая СУБД этого не сделает, и в плане безопасности принцип, все данные только читать а изменять после проверки не зависит от СУБД. Так что InterBase, MS SQL или Oracle без разницы. На прежнем месте работы в банке Oracle использовался, но система примерно также была организована. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 14:10 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
nervСкажем на панели инструментов есть кнопки со всеми функциями. При нажатии на кнопку для редактирования конечно же будет своя некая форма. Так проверка пользователя должна пройти до вызова этой формы, Предпочитаемый мной подход: каждому функциональному действию указать, какая роль в БД необходима для его выполнения. В случае дельфы очень просто - заводится соответствующее свойство у компонента-наследника TAction. После логина приложение считывает роли пользователя; соответственно action может в соответствии с этим списком регулировать свои visible/enabled, выдавать при нажатии "не хватает прав, нужна роль такая-то" и все прочее, что взбредет в голову. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 17:39 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
softwarerПредпочитаемый мной подход: каждому функциональному действию указать, какая роль в БД необходима для его выполнения. В случае дельфы очень просто - заводится соответствующее свойство у компонента-наследника TAction. Очень интересная и соответствующая моим запросам идея! Только вот с ролями я не сталкивался, всегда делал отдельной таблицей, где для каждой операции прописывал ID пользователей, которые могут эту операцию выполнять. В данной программе как раз таки нужно ограничить доступ штатными средствами MS SQL. Поэтому, softwarer , пожалуйста, расскажите чуть подробнее о своей идеи. Выдержки из кодов приветствуются. 1) Назначение ролей. Как? (можно направить к BOL, указав соответствующую функцию). softwarer После логина приложение считывает роли пользователя; соответственно action может в соответствии с этим списком регулировать свои visible/enabled, выдавать при нажатии "не хватает прав, нужна роль такая-то" и все прочее, что взбредет в голову. 2) Вот тут небольшой бы пример кода. Скажем проверить есть у пользователя (точнее роли) право на просмотр некоего View. Если нет, сделать Button невидимым (Hide). softwarerВ случае дельфы очень просто - заводится соответствующее свойство у компонента-наследника TAction. 3) никогда не использовал свойство TAction. Можно тоже небольшой пример кода, пожалуйста. Благодарю за выдержку и терпение, проявленное ко мне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 13:46 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
nervвсегда делал отдельной таблицей, где для каждой операции прописывал ID пользователей, которые могут эту операцию выполнять. nerv1) Назначение ролей. Как? (можно направить к BOL, указав соответствующую функцию). Думаю, на это лучше ответят в форуме по MSSQL. Если бы мне было лень делать нормальный поиск по доке, я бы поискал что-нибудь типа sp_addrole. nerv2) Вот тут небольшой бы пример кода. Скажем проверить есть у пользователя (точнее роли) право на просмотр некоего View. Если нет, сделать Button невидимым (Hide). Хм. Ну во-первых, получить список ролей (я это делаю так, но Вам это вряд ли подойдет) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. и сохранить в каком-нибудь StringList-е. Во-вторых, добавить в Action свойство скажем RoleRequired и обработчик типа Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 14:48 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
softwarer Хм. Ну во-первых, получить список ролей (я это делаю так, но Вам это вряд ли подойдет) Код: plaintext 1. А что это за таблица session_roles . Я ее не нашел ни в master, ни в msdb ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 15:07 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
Это view, и она в Oracle ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 21:05 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
softwarerЭто view, и она в Oracle ;) Ну это ладно, имена ролей допустим я узнаю, в MS SQL нашел как это можно вытащить. А вот с Action все таки поподробнее распишите, пожалуйста. может на простом примере каком-нибудь. Обычный буттон скрыть, если такой роли нет, например, как это сделать через Action? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 14:10 |
|
||
|
Посоветуйте
|
|||
|---|---|---|---|
|
#18+
nervОбычный буттон скрыть, если такой роли нет, например, как это сделать через Action? Хм. Так же, как вообще все что угодно скрывается через Action. nerv , простите, но я полагаю несколько неуместным беседовать в "Проектировании БД" о тематике форума "Delphi". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 14:35 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1545324]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
144ms |
get topic data: |
10ms |
get first new msg: |
6ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 448ms |

| 0 / 0 |
