Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Триггеры... А стоит ли использовать... [MSSQL]

Страницы: 1 2 3 >
Rafe © (2003-12-07 17:14:00)

Всем привет! Никогда не использовал триггеры. Обходился ХП. Есть такая задача: при изменении значения в поле одной таблицы изменять значение (по определенному правилу) в другом поле этой же записи этой же таблицы. По аналогии вычисляемых полей. Стоит ли для этого использовать триггеры. Объясню на простом примере:

Tab1
---------------
Fld1 Fld2

И надо на изменение (UPDATE) значения в поле Fld1 изменить значение, например в поле Fld2 = 3*Fld1.

Стоит ли использовать Триггеры или нет?
Если у кого есть опыт в написании триггеров, просьба, если не сложно, написать его на основе данного примера.

Erik (2003-12-08 17:55:00) [1]

Чего вы спорите в SP можно сделать select на туже таблицу, а в тригере нельзя! Нам SAP селую систему на Oracle сделела. Практически все на SP на таблицы у user нет прав даже на чтение таблиц. Все очень удобно, свобода в модификации данных. Используем 5 лет.

Ega23 (2003-12-08 16:16:00) [2]

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

А вот эта мысль мне что-то в голову не приходила. За идею - спасибо.
Но как быть с правами доступа к sp и таблицам? Если их временно надо поменять?

Danilka (2003-12-08 16:12:00) [3]

> [38] Ega23 (08.12.03 16:00)

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

Ega23 (2003-12-08 16:00:00) [4]

OperCod OperName
------- --------------------------------------------------------
0 Доступ к модулю БЮРО ПРОПУСКОВ
1 Завершение работы с модулем БЮРО ПРОПУСКОВ
2 Аудит БЮРО ПРОПУСКОВ
10 Работа с персоналом
11 Добавление сотрудника
12 Изменение данных сотрудника
13 Удаление данных сотрудника
14 Печать учетной карточки
15 Изменение пин-кода
30 Работа с пропусками
31 Добавление нового пропуска в БД
32 Изменение данных пропуска
33 Удаление пропуска из БД
34 Поиск по пропуску
35 Выдача нового пропуска сотруднику
36 Изъятие пропуска у сотрудника
40 Работа с планом доступа
41 Назначить план доступа
42 Изменить план доступа
43 Удалить доступ
44 Сверка назначений
45 Диспетчер назначений
50 Специальные функции
51 Изменение периода доступа сотрудника
52 Назначение группового разового доступа
53 Добавление назначений по образцу
54 Экспорт активной таблицы
61 Фотографирование сотрудника
62 Печать пропуска
63 Взвешивание сотрудника
64 Удаление фотографии
65 Неудачная печать пропуска
66 Печать неидентифицир. пропуска
80 Доступ к протоколу
81 Очистка протокола
100 Доступ к настройкам системы
101 Просмотр списка пользователей
102 Модификация данных пользователя
103 Просмотр списка организаций и подразд.
104 Модификация данных об подразделениях
105 Просмотр списка должностей
106 Модификация данных о должностях
107 Просмотр списка рабочих станций
108 Модификация данных о рабочей станции
109 Просмотр списка АРМ
110 Модификация конфигурации АРМ
111 Просмотр списка типов пропусков
112 Просмотр списка статусов пропусков
113 Просмотр списка производителей пропусков
114 Просмотр списка доп.признаков пропусков
115 Модификация списка доп.признаков пропусков
116 Модификация данных об организации
117 Просмотр параметров
118 Модификация параметров
119 Модификация конфигурации АРМ
120 Модификация конфигурации устройств
121 Просмотр временных окон
122 Модификация временных окон
123 Просмотр расписаний доступа
124 Модификация расписаний доступа
125 Просмотр типов дней
126 Модификация типов дней
127 Просмотр планов доступа по дням
128 Модификация планов доступа по дням
129 Просмотр календаря
130 Модификация календаря
131 Генерация календаря
132 Просмотр групповых планов доступа
133 Модификация групповых планов доступа
134 Просмотр списка праздничных дней
135 Модификация праздничных дней
136 Просмотр графиков
137 Модификация графиков
500 Доступ к оперативным сводным
501 Просмотр списка сотрудников
502 Просмотр сводной по сотруднику
503 Просмотр табелей сотрудников
504 Просмотр сводной посещений по гостевым пропускам
505 Просмотр сводной по конфигурации АРМ
506 Просмотр сводной по выданным гостевым пропускам
507 Просмотр сводной по системе
508 Просмотр сводной по расписанию
509 Просмотр сводной по перемещениям
998 Системная операция
999 Неизвестная операция
0 Доступ к отчетно-аналитической системе
1000 Персонал и пропуска
1010 Список сотрудников
1020 Выданные гостевые пропуска
2000 Перемещения
2020 Проходы через ТД
2030 Пребывание в зоне
3000 Система
31000 Специальные
31510 Импорт из CardBase
31520 Экспорт в CardBase

(97 row(s) affected)

Все эти 97 операций должны отслеживаться на клиенте: страничку у PageControl не переключить, если нельзя; кнопку Disable сделать, если операция запрещена и т.д.
Список этих операций постоянно растет. И что проще: изменить пару SP и exe-шник и переслать клиенту по почте, либо ехать на объект и добавлять операции во все роли и перераздавать права на процедуры с таблицами?
А если на объекте заболел тот товарищ, который пропуска печатает? Тогда временно другому пользователю системы дают эти права непосредственно из пользовательского интерфейса, а потом, когда надо, их отбирают.
Таким образом заказчик получает возможность самому распределять роли между операторами, при этом совершенно не зная о том, что есть какой-то Enterprize Manager и Query Analyzer.

Shirson (2003-12-08 15:52:00) [5]

>Ega23 (08.12.03 14:39) [29]
Делаем следующее:
Создаем в базе таблицу из одной записи - зашифрованного логина и пассворда. Юзер коннектится из экзешника именно к этой таблице, т.к. по тому логину с пассвордом ты получаешь доступ к базе только на чтение этой самой одной-единственной таблицы.
Далее, получив из базы уже реальный аккаунт, делаем реконнект.
Теперь полные права на базу.

Вариант получше, но всё равно не то. Пароль расшифровывается на клиенте и через него-же идёт коннект к базе. Значит всё, что нужно для расшифровки есть в клиенте.

Ладно, это дебри безопастности и не о том речь.

Триггеры и sp гармонично друг друга дополняют и прекрасно работают вместе, не вытесняя друг друга. Только на триггерах или только на sp сделать хорошую вещь - вряд ли.

MOA (2003-12-08 15:43:00) [6]

>Совершенно необязательно, что доменный администратор будет вообще иметь доступ к этой базе
И на здоровье! Действуем так:
Тщательно анализируем роли, которые будут иметь место в нашей базе (на этапе постановки задачи. Корректируем "по ходу"). Раздаём права ролям.
Тщательно разбиваем юзеров на группы Windows - согласно их роли в организации. Мы подсказываем админу сети, какие группы нам могут понадобится, если админу БД это нужно.
Затем админ БД помещает нужные группы в роли базы. Если есть небольшие отклонения (ну, например, данную роль имеет только один юзер) - админ базы вводит в роль именно этого одного пользователя.
Дело-то в том, что эту работу всё равно придётся делать, но возникают большие сомнения в недырявости "самопального" решения + расходы на разработку такого решения.

Ega23 (2003-12-08 15:28:00) [7]

> Конечно, на сверку можно так.Но откуда вычитать права на
> печать (или еще что-либо по фантазии заказчика).Ну вобщем
> бывают случаи, как ни крути

ВО! Это и есть именно такой случай. Более того, такой "экзотики" там - пруд пруди. Печатать отчеты, назначать расписания на магнитную карту, фотографировать сотрудника и т.д. и т.п.

Ega23 (2003-12-08 15:24:00) [8]

> А чем не подходят роли базы и группы Windows? - Ведь если
> их использовать, юзеров в базе и на сервере не нужно прописывать
> вообще. А роли в том или ином виде - "самопальном" или готовом
> - делать всё равно ведь придётся.
> По вопросу - я бы не стал хранить в базе вычисляемые поля,
> если это не "вспомогальная" таблица (которая удалится стразу
> после создания), поскольку нарушение основной идеи "каждое
> значение ровно в одном месте". Зачем хранить то, что вычисляется?

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

Silver Alex (2003-12-08 15:21:00) [9]

> SergSuper (08.12.03 14:58) [32]

> Написать процедуру сверки и раздавать на неё права, а на
> сами таблицы права не давать. Или только на чтение. Какие
> проблемы то?

Конечно, на сверку можно так.Но откуда вычитать права на печать (или еще что-либо по фантазии заказчика).Ну вобщем бывают случаи, как ни крути

SergSuper (2003-12-08 14:58:00) [10]

Опять соглашусь с Ega23.Можно конечно для 1000 операторов завести логины в самой базе, и на уровне базы раздать права. Но это в стандартной ситуации где добавление, изменение , удаление. А нам нужны права допустим на сверку документа, вот тут метод Ega23 как раз подходит(сам так делаю) .

Написать процедуру сверки и раздавать на неё права, а на сами таблицы права не давать. Или только на чтение. Какие проблемы то?

Если возвращаться к исходной теме - для чего надо использовать триггеры.
Например у меня есть таблица проводок(это для бухгалтерии). Вставка/удаление проводки изменяет остатки на соответствующих счетах. У меня на проводки стоит триггер и откуда бы я проводки не вставлял - я не беспокоюсь об остатках. И удалять могу проводки не процедурой, а delete-ом по условию. При этом доступ к остаткам есть только на чтение. Ну и заодно протоколирование обеспечивается. Мне кажется для таких случаем процедура была бы не так удобна.

Danilka (2003-12-08 14:57:00) [11]

[29] Ega23 (08.12.03 14:39)
вобщем-то я не большой спец по МС-Скулю, но, если ты ломишся ни сервер через ОДБЦ, то можно сделать так:
заходишь в администратор источников данных ОДБЦ, запускаешь трассировку, запускаешь свою программу, смотришь лог, того что она делала, из которого видишь, что она заломилась с одним паролем, прочитала данные из такой-то таблицы, перелогинилась, а дальше сам повторяешь ее действия откуда угодно.
ну, а имея реальные логины с паролями и не имея никаких ограничений со стороны сервера делаешь что душе угодно. :)

> [30] MOA © (08.12.03 14:51)
> А чем не подходят роли базы и группы Windows

они и подходят, в самый раз.

MOA (2003-12-08 14:51:00) [12]

А чем не подходят роли базы и группы Windows? - Ведь если их использовать, юзеров в базе и на сервере не нужно прописывать вообще. А роли в том или ином виде - "самопальном" или готовом - делать всё равно ведь придётся.
По вопросу - я бы не стал хранить в базе вычисляемые поля, если это не "вспомогальная" таблица (которая удалится стразу после создания), поскольку нарушение основной идеи "каждое значение ровно в одном месте". Зачем хранить то, что вычисляется?

Ega23 (2003-12-08 14:39:00) [13]

> Shirson © (08.12.03 14:29) [28]

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

Shirson (2003-12-08 14:29:00) [14]

Если прога имеет возможность выполнять операции на сервере, значит она имеет серверный логин и серверный пароль.
Если она их имеет, они могут быть из неё извлечены. На 99% уверен, что они там хранятся "на виду".
Отсюда вся эта навороченная безопастность получается опастностью.

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

Ega23 (2003-12-08 14:29:00) [15]

Во!
Наконец-то хоть кто-то понял, зачем вся эта байда с собственными паролями была нужна. просто это тяжело вот так в письменном виде и кратко объяснить.

Silver Alex (2003-12-08 14:19:00) [16]

теперь уже тут обсуждают безопасность? :))
Опять соглашусь с Ega23.Можно конечно для 1000 операторов завести логины в самой базе, и на уровне базы раздать права. Но это в стандартной ситуации где добавление, изменение , удаление. А нам нужны права допустим на сверку документа, вот тут метод Ega23 как раз подходит(сам так делаю) .Опять же если дать продвинутому пользователю логин и пароль к серверу значит он может туда залезть в обход клиентской программы, а это уже чревато последствиями

SergSuper (2003-12-08 14:18:00) [17]

>Ega23 (08.12.03 13:17) [18]

Операторов может быть хоть 1000. И что, каждому отдельно на сервере БД заводить логин и права прописывать?
Согласитесь что это в любом случае надо где-то прописывать и если Вы считаете что доморощенные средства лучше стандартных, то почему бы Вам и сервер свой не написать?

Каждый оператор из клиентской программы коннектится к серверу под одним и тем-же аккаунтом (которого он не знает). Параметры этого коннекта в экзешнике программы намертво прошиты, это константы. А вот в самой MyКСС (см. выше) оператор должен зарегистрироваться, чтобы получить набор разрешённых действий на клиенте, и чтобы оставить след в протоколе.
Ну вобще-то плакать хочется читая такое. Я еще понимаю когда это делается в трёхзвенной архитектуре или чтобы уменьшить количество коннектов для экономии на лицензиях. Но вместо того чтобы грамотно раздать права городить свою систему паролей...

Ega23 (2003-12-08 14:05:00) [18]

Да знаю я эту политику безопасности.
Проблема гораздо более приземленная - где ты найдешь толкового сисадмина, который пойдет на штатную должность в бюджетном предприятии. максимум на что он там может рассчитывать - 10 штук. Так что это проблема кадров. Нужно сделать так, чтоб юзера вообще Enterprise Manager запустить не могли. И в master с msdb сами ручками лазить не могли. Им вообще не надо знать, что это такое.

Danilka (2003-12-08 13:52:00) [19]

[22] Ega23 (08.12.03 13:46)
с учетом того, что логин с паролем зашиты в экзешнике, то узнать их - не проблема.

совсем другое дело, когда за доступом следит сам сервер - чего можно этому логину, а чего нельзя. в этом случае, дальше того, что разрешено этому конкретному юзеру ничего сделать нельзя будет никимими средствами.

Ega23 (2003-12-08 13:46:00) [20]

> Вот про то и речь. Берём этот пароль и лезем в базу в обход
> её навороченности.

А вот чтоб такого и не было.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »