Переход на MS SQL

← →
Romkin © (2002-07-26 14:25) [0]

Возникла тут задумка, перейти с Interbase 6 на MS SQL 2000.
Да только вопросы возникают, будет ли быстрее, да и как перевести.
А конкретно - есть скрипт на IB http://www.romkin.pochtamt.ru/script.htm
Меня интересует, можно ли перевести триггеры у accountbook на MS SQL, и как это выглядит? Кому не трудно, гляньте плиз. Никак не могу разобраться с транзакциями в MS SQL и триггерами

← →
Polevi © (2002-07-26 14:33) [1]

в IB триггер срабатывает для каждой измененной записи - в MS SQL он срабатывает один раз - старые и новые значения хранятся в таблицах inserted и deleted

вместо for select используй временные таблицы

← →
Eduard © (2002-07-26 14:36) [2]

Переписывать придется много. В MSSQL нету Domain`ов, а есть Default`ы, а триггер будет выглядеть где-то так:

CREATE TRIGGER ACCOUNTBOOK_CHECK_INSERT ON dbo.ACCOUNTBOOK
FOR INSERT
AS
BEGIN
IF (NEW.COUNTNUM <= 0) THEN
RAISEERROR(...;
IF (NOT NEW.INOUT_SIGN IN (-1,0,1)) THEN
RAISEERROR(..);
END

...ну еще много-много отличий.

← →
Eduard © (2002-07-26 14:37) [3]

... а, вообще-то, NEW там тоже нету.

← →
Romkin © (2002-07-26 14:50) [4]

Так весь смысл в том, что триггер должен сработать после вставки записи в базу, в триггерах after у таблицы accountbook проверяется остатки товара, критерий - если в какой-то момент времени остаток отрицательный - выдать ошибку (ну и изменения откатываются, конечно) Фактически accountbook содержит записи о приходе/расходе товара. Так вот, триггер просто суммирует остатки с учетом сделанных изменений. Можно ли как-нибудь так же просто на MS SQL? И когда там триггер срабатывает, до проверки foreign keys или после?
И еще, MS SQL вроде блокирует записи, а при изменениях в accountbook много записей в WH_REMAIN изменяется, это остатки на конец дня. Другие пользователи смогут работать? Правда, при тесте на 500000 записей (10 лет) IB обрабатывал запись в середине за 2-3 сек, но все равно нежелательно, если будет deadlock.
2Polevi: спасибо, сместо некоторых процедур пойдут view, это я уже понял
2Eduard: а транзакцию откатывать надо?

← →
Kapusto © (2002-07-26 15:04) [5]

По порядку.
1. Триггер срабатывает _после_ проверки всех констрайнтов, так что каскадное удаление на триггерах и просто foreign key не совместимы
2. делаешь raiserror, rollback transaction
3. Все зависит от того, как настроишь уровни изоляции и блокировки

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

← →
Romkin © (2002-07-26 15:35) [6]

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

← →
Kapusto © (2002-07-26 15:51) [7]

Лично я бы всю твою логику перенес бы из триггеров на ХП, отобрал бы у пользователей все права на таблицы, кроме select...
А насчет быстрее ли будет работать - завсит от того, кто будет рулить серваком, и на чем он будет крутиться...
При равных не особо благоприятных условиях (админ - лох, тачка слабая) IB имхо в сильном выигрыше...

← →
Romkin © (2002-07-26 16:19) [8]

Ему еще и админ нужен?! Постоянно? Зачем?
тачка в принципе средняя - PIII-600 128 метров... Правда, как для MSSQL - не знаю, IB на такой будет держать коннектов 20-30 без проблем и задержек. А вот сбережения питания нет, для MS SQL критичны обрывы питания?
А насчет прав пользователей - я их не писал, изменения метаданных закрыты.
из триггеров на ХП... Этож какое приложение получиться - брать данные из select, а изменять ХП, да еще и отдельной ХП на обновление/удалени/изменение? Замучаешься запросы на клиенте писать, сейчас-то все автоматически. Да и структура пострадает, а ее описывать. И что писать в руководстве к базе?
Кошмар...
Выходит, все переписывать заново :-((

А если уж переделывать заново - стоит отказаться от бизнес-логики в триггерах, а перенести её в ХП. И вообще при проектировании серьёзной БД, нужно стразу определяться с правилами внесения изменений - разумеется исключительно через те-же хранимые процедуры.

Для MSSQL2000 "PIII-600 128 метров" на "коннектов 20-30" хватит за глаза

2Romkin: Хотелось бы мне посмотреть, как ты в триггере на обновление будешь обновлять ту же самую таблицу :)
а насчет отдельных процедур - ну у тебя же трехзвенка, все можно автоматизировать на сервере приложений...

> Kapusto © (26.07.02 16:59)

Без проблем, уверяю тебя!
> Romkin
Мы в свое время тестировали, получалось намного быстрее, однако..
Но не буду распространяться, так как корректность теста, да еще и на разные БД - это флеймовая тема

Переход на MS SQL Найти похожие ветки