Мастера 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.

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

Danilka (2003-12-08 13:29:00) [21]

> Операторов может быть хоть 1000. И что, каждому отдельно
> на сервере БД заводить логин и права прописывать?

Неужели это так сложно?

> А вот в самой MyКСС (см. выше) оператор должен зарегистрироваться,
> чтобы получить набор разрешённых действий на клиенте, и
> чтобы оставить след в протоколе.

Все-таки непонимаю, зачем все это? Значит, в самой программе зарегистрироваться - без проблем, а еще одного юзера на сервере завести - проблема? Зачем изобретать велосипед, делать то, что уже давно сделано, то что делается элементарно штатными средствами?

Ega23 (2003-12-08 13:25:00) [22]

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

куда ты с ним полезешь? Это не есть аккаунт. Для сервера это ничто. Эта вещь имеет смысл только для клиентской программы. И ВСЕ.

Shirson (2003-12-08 13:19:00) [23]

>Пароль не на сервер, не на NT, этот пароль, под каким юзер в самой базе числиться

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

Ega23 (2003-12-08 13:17:00) [24]

> SergSuper (08.12.03 13:03) [17]

Сначала дам СВОЕопределение: MyКСС - МОЯ клиент-серверная система, т.е клиентская программа + СУБД (MSSQL 7.0)+ сама база.

Операторов может быть хоть 1000. И что, каждому отдельно на сервере БД заводить логин и права прописывать?
Каждый оператор из клиентской программы коннектится к серверу под одним и тем-же аккаунтом (которого он не знает). Параметры этого коннекта в экзешнике программы намертво прошиты, это константы. А вот в самой MyКСС (см. выше) оператор должен зарегистрироваться, чтобы получить набор разрешённых действий на клиенте, и чтобы оставить след в протоколе.

SergSuper (2003-12-08 13:03:00) [25]

Из клиентской программы при старте запускается sp с параметрами: Логин (личный логин оператора для системы, не для NT), Пароль, PCName ().

Логин и имя рабочей станции можно узнать и из переменных коннекта. А пароль должен сервер проверять когда к нему логинятся. Т.е. процедуру можно упростить выбросив лишние параметры

Ega23 (2003-12-08 12:27:00) [26]

Мде... а броадкаст не пробовали в сеть делать? С этим паролем? :)
Пароль не на сервер, не на NT, этот пароль, под каким юзер в самой базе числиться.
В базе есть отдельная таблица операторос с их логинами и паролями. Нужно это для получения кода оператора и определения его прав на клиенте - не буду же я разные программы для опреатора, администратора, пользователя и ещё черт знает какой конфигурации писать. Все это одна и та же программа, просто чем больше у тебя прав, тем больше в ней открывается возможностей.

Ega23 (2003-12-08 12:21:00) [27]

> Silver Alex ©

Полностью согласен.

Shirson (2003-12-08 12:21:00) [28]

>Ну это мы пришли к безопасности сервера. Конечно, взломать можно всё. Но если у тебя NT-шные права в сети - обычный user, если физически вынут CD-ROM, если серверная закрыта от тебя на 3 замка, если ты понятия не имеешь, под каким Login"ом ты к серверу коннектишься, то взломать его оччень непросто.

>Из клиентской программы при старте запускается sp с параметрами: Логин (личный логин оператора для системы, не для NT), Пароль, PCName (имя рабочей станции).

Мде... а броадкаст не пробовали в сеть делать? С этим паролем? :)
Или в FAR на программе F3 нажать и посмотреть, какой пароль заносится в sp? :)

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

> ну-ну. пишу скрипт на жаба-скрипте - 4 строки, который инсертит
> напрямую в таблицу. записываю его в файл с расширением js.
> запускаю. и весь твой мегаправильный сервер лажается по
> самое нехочу. а клиент вообще отдыхает, ибо не трогали его.
> конечно, надуманный пример, но все равно, ты глубоко заблуждаешься,
> если считаешь, что за всю историю жизни этой БД, с которой
> сейчас ты работаешь, ты будешь единственным разработчиком.
> :))

Ну это мы пришли к безопасности сервера. Конечно, взломать можно всё. Но если у тебя NT-шные права в сети - обычный user, если физически вынут CD-ROM, если серверная закрыта от тебя на 3 замка, если ты понятия не имеешь, под каким Login"ом ты к серверу коннектишься, то взломать его оччень непросто.
А разработчику даже иногда (не всегда, но иногда) полезно бывает, чтобы "следов не осталось" :-)

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

Из клиентской программы при старте запускается sp с параметрами: Логин (личный логин оператора для системы, не для NT), Пароль, PCName (имя рабочей станции). По этим параметрам определяется ID рабочей станции, ID оператора, его права и т.д.
Таблица протокола как раз и состоит из : Текущее время, ID оператора, ID раб. станции и ID действия, которое он делал (например - добавление нового сотрудника). Ну и плюс всякие примечания.
Так вставку в протокол через триггер не сделаешь. Или в таблицу персонала надо ещё 2 поля добавить: Код оператора и Код раб. станции.

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

согласен с Ega23 в данной ситуации все просто, можно обойтись и триггером.Но бывает ситуация когда действительно легче обойтись SP.Ну а если что-либо делать "по злому умыслу, по забывчивости ..", то никакой триггер не спасет

Desdechado (2003-12-08 12:11:00) [31]

а по 1-му вопросу - почему бы и в самом деле вычисляемое поле не использовать?

Danilka (2003-12-08 11:55:00) [32]

[9] Ega23 (08.12.03 10:43)

> О каком грамотно настроенном сервере (и клиенте) тогда
> идет речь, если он может напрямую сделать инсерт в таблицу?

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

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

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

Ega23 (2003-12-08 10:43:00) [33]

> Danilka ©

> Shirson ©

Все верно. Все вы правильно пишите. Но:

> если я сделаю инсерт напрямую в таблицу.

О каком грамотно настроенном сервере (и клиенте) тогда идет речь, если он может напрямую сделать инсерт в таблицу?

> Обеспечивать реакцию базы на изменения в таблице простыми
> sp - шаг назад. И неважно, как настроен сервер. Как бы грамотно
> его не настраивали, если на таблице нет триггера, значит
> эту таблицу можно модифицировать и база об этом не узнает.
> Поэтому sp не заменит триггера. Иначе бы никто не придумывал
> триггеры.

Ситуация: есть таблицы персонала, пропусков, расписаний доступа и т.д., всего около 50-ти штук. Практически каждое изменение во всех этих таблицах произведенное оператором должно отражаться в таблице протокола. Вопрос: как тогда в триггер передать код оператора и код рабочей станции?
Так что я ничего не имею против триггеров, но сам их использовал раза 2 всего. Правда, в той ситуации действительно не помогла бы никакая SP.

Shirson (2003-12-08 10:28:00) [34]

Триггер, это sp, которая запускается при модификации таблицы, и "входным параметром" является таблица модификации (inserted или deleted) - то, что было удалено/вставленно из/в таблицу, на которой висит триггер.

Обеспечивать реакцию базы на изменения в таблице простыми sp - шаг назад. И неважно, как настроен сервер. Как бы грамотно его не настраивали, если на таблице нет триггера, значит эту таблицу можно модифицировать и база об этом не узнает. Поэтому sp не заменит триггера. Иначе бы никто не придумывал триггеры.

Danilka (2003-12-08 10:27:00) [35]

[5] Ega23 (08.12.03 10:21)
между прочим, триггер служит совсем не для того, чтобы заменять ХП.
а ХП ну никак не заменит триггер, даже при самом грамотно настроенном сервере в мире, если я сделаю инсерт напрямую в таблицу. :))

Fay (2003-12-08 10:23:00) [36]

>> если грамотно настроен сервер - SP может всегда заменить
>> триггер
Бред

Ega23 (2003-12-08 10:21:00) [37]

> Оригинально...
> И что с нем не так просто? Или, вопрос с другого ракурса
> - чем триггер отличается от sp?

Скажем так: для конечного клиента, если грамотно настроен сервер - SP может всегда заменить триггер, а вот наооборот - не всегда.

Shirson (2003-12-08 09:27:00) [38]

Оригинально...
И что с нем не так просто? Или, вопрос с другого ракурса - чем триггер отличается от sp?

Есть такое понятие, как целостность базы данных. Если база должна реагировать на изменения в таблице, это делается триггером. Тут целостность сохранена. Потому что любое изменение, неважно, чем вызванное, будет проходить через триггер.

Если это делается отдельной sp, то найдётся ситуация, когда кто-то (по злому умыслу, по забывчивости или еще дюжине причин), долбанёт туда insert. И целостность поплыла в далёкие края. Т.е. достоверность таблицы, за реакцию на модификацию которой отвечает КЛИЕНТ, стремится к 0.

Ega23 (2003-12-08 09:01:00) [39]

С одной стороны, триггеры для этого и предназначены.
Но, на мой взгляд, удобнее обходиться sp-хой. Ведь на клиенте большой разницы нет:
написать Insert into Tab1 (Fld1) Values (1)или Exec sp_MySP @mode=1, @Value1=1
Но если ошибха в sp-хе, то её перенакатить элементарно, а вот с триггером все не так просто.

Shirson (2003-12-08 08:24:00) [40]

блин, поля переставил :(

set nocount on update Tab1 set Fld2=Fld1*3 where id in (select max(id) from inserted)

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

Наверх

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