IB или MS SQL Server

← →
McSimm (2002-02-26 12:57) [40]

>ev © (25.02.02 18:20)
Мне сейчас трудно ответить, разложив по полочкам - это накопленное отношение. Например в IB очень легко (насколько помню) организовывается транзакция в стиле
try
любая работа
except
rollback-exit при любой ошибке
end
commit если небыло ошибок

- В MS-SQL во многих процедурах мне пришлось писать некрасивый код после каждой команды. - Процедура на 60% состоит из проверки на ошибку и принятия решения commit-rollback
- Вложенность какая-то ненастоящая.
- Открывая транзакцию приходиться гадать, а где же она закроется? Во вложенном вызове процедуры или в тригере каком?

- Однажды у меня из-за глюка осталась открытая транзакция (открыл по глупости из клиентского приложения). В конце дня каким-то образом база сделала rollback этой транзакции (по-видимому в результате backup операции). Так из базы пропала почти вся информация добавленная в нее после открытия транзакции.
База буквально откатилась к утреннему состоянию. Но не полностью, а какими-то загадочными участками. (Некоторые справочники сохранили информацию)
При этом дневная работа не имела к этой транзакции прямого отношения - разные пользователи, разные компьютеры.
В IB откат транзакции откатит только то, что выполнено в ее контексте

>Что в MS-SQL нет механизма триггеров.
Есть, но не такие удобные.

← →
Володя Т. (2002-02-26 13:11) [41]

А мне вот задачку год назад довелось решать :) Надо чтобы все написанное за 5 лет в IB работало и в MS, и чтобы exe-файл один был для все равно какой СУБД. Получил удовольствие от ее решения :)

← →
ev (2002-02-26 14:52) [42]

Т.е. подведя итог всему сказанному, можно сказать: пользуйся IB, хотя MS SQL - лучше, но плохо работает!
Я правильно понял?

← →
Delirium (2002-02-26 15:03) [43]

> Deniz
"А причем здесь транзакция? Триггер это набор некоторых действий, которые выполняются до/после изменения(insert, update, delete) таблицы. А транзакцию уже пользователь завершает по кнопкам сохранить/отменить" - каждое "изменение" и есть минимальная тразакция, и триггер активирутся только после успешного её завершения. Как ты представляешь себе триггерную целосность если была бы возможность в триггере откатить или модифицировать вызвавшую его транзакцию? Триггеры работают исключительно с результатами работы транзакций, и в свою очередь, могут модифицировать эти результаты. Таким образом, аргумент (в контексте вышео значенного спора с McSimm) в пользу before триггеров - это просто уловка, как я понимаю, для обхода декларативной целостности, что собственно её и нарушает. Именно по этому в MSSQL этого нет и не надо.

← →
McSimm (2002-02-26 15:04) [44]

Я бы такой итог не подвел.
Почему плохо работает? Хорошо работает.
Есть определенная специфика. К чему-то надо привыкнуть, с чем-то смириться, чего-то избегать.
Тому кто с IB не был знаком до MS-SQL - вообще хорошо :)

← →
Awex (2002-02-26 15:48) [45]

В этой бесседе потерялась одна нить, это как спроектированнна база. То есть какой подход быль использован.
Существует 2 типа построения базы:
1. От отчета
2. От данных.
И напрасно требовать быстрого построения отчета от базы спроектированной по 2 принципу. Нужно сразу проектировать базу на максимальную скорость получение отчета.

← →
Кулюкин Олег (2002-02-26 17:41) [46]

2 Dimedrol ©
> К стати, разве не является БОЛЬШУЩИМ плюсом то, что ИБ работает под Линухом, и имеется в OpenSource варианте ?!
> По-моему - бесспорно!
Поднимите руки те, кто правил исходники ИБ?
В реальной жизни кому-либо его OpenSource"овость пригодилась?

По личным ощущениям отдаю преимущество MS SQL.
Его минусы - нужна более мощная машина нежели для ИБ. Посложнее администрировать (это не смертельно).
Плюсы - большие возможности SQL.
Стабильно работает с большими объемами данных.

← →
Bachin (2002-02-26 21:21) [47]

2Deniz: Я бы конечно за такой код ручки ... :))) ну да это не важно.
я считаю, что если я пишу "заблокировать всю таблицу" и при этом другой пользователь просит данные, причем commited! а я уже начал транзакцию (как в вашем примере) - то по-другому НЕ МОЖЕТ И БЫТЬ!
Так что уж батенька решайте: либо код человеческий писать либо пользоваться IB.
Кстати, это был примет Клиента, а не сервера. А откройте мне плиииз транзакцию на сервере...
А еще лучше, что-то типа:

begin transaction t1
...
save point sp1
begin transaction t2
...
if troubles then rollback to sp1 else commit t2
...
commit t1
----------------------------------------------
или даже просто в триггере при вставке в t1 вставьте запись в t2, сделайте для t2 commit, а потом для t1 rollback
----------------------------------------------
и еще (возможно я всетаки не прав - ооочень надеюсь): с пару месяцев назад мне в этой конфе сказали, что в IB НЕТ именных транзакций. Если это не правда - покажите плиииз ооочень нужны...

← →
evgeg (2002-02-26 22:37) [48]

> что дороже, то и лучше.
Чушь. Не верится, что есть люди, которые могут так думать по настоящему.

> Поднимите руки те, кто правил исходники ИБ?

Здесь ты таких людей, может, и не найдешь, а вот на ib.demo.ru их полно.

> 1. справиться IB с ОЧЕНЬ большим объемом данных?
Какой объем данных ты считаешь очень большим? C сотнями терабайт надо брать Oracle.

> 2. как по безопасности IB?
А что нужно то? Чем MS SQL безопаснее?

← →
DSR (2002-02-27 08:58) [49]

IB
MSSQL

← →
McSimm (2002-02-27 10:51) [50]

>Bachin (26.02.02 21:21)
>2Deniz:
Подозреваю, что это мне :)

try-except-end я написал для показа принципа, имел в виду,например, stored proc.
>if troubles then
Вот с получением этого troubles как раз и проблемы:

SET @Error = 0
...Здесь полезная команда;
SET @ErrorSave = @@ERROR
IF (@ErrorSave <> 0) SET @Error = @ErrorSave
...Здесь полезная команда;
SET @ErrorSave = @@ERROR
IF (@ErrorSave <> 0) SET @Error = @ErrorSave
...Здесь полезная команда;
SET @ErrorSave = @@ERROR
IF (@ErrorSave <> 0) SET @Error = @ErrorSave
и так 52 раза
IF @Error = 0
COMMIT TRANSACTION @TransactionName
ELSE
ROLLBACK TRANSACTION @TransactionName

Уже не помню как в IB, но помню, что это было очень красиво и лаконично.

>Так что уж батенька решайте: либо код человеческий писать либо пользоваться IB.
Ну это явно перебор. Причем в противоположную сторону

← →
Володя Т. (2002-02-27 11:33) [51]

> McSimm © (27.02.02 10:51)
> Уже не помню как в IB, но помню, что это было очень красиво
> и лаконично.

Если можно, постараюсь напомнить: в IB вообще ничего кроме полезного кода в этом случае можно не писать. В случае неудачи возникнет exception недостаток которых в MS я сильно переживал. rollback писать не надо, он сам произойдёт, да и commit в случае транзакции по умолчанию тоже излишен.

← →
McSimm (2002-02-27 11:54) [52]

>Володя Т. (27.02.02 11:33)
Спасибо. Я именно об этом.
При этом вложенность транзакций настоящая, а не savepoints. Если не ошибаюсь, все данные в IB представимы по версии транзакции - уникальное растущее значение. Отличный механизм.

К слову - я не вступил в спор относительно тригеров, которые якобы обязаны завершать транзакции и пр. только потому, что все эти утверждения совершенно безосновательны.
Внутри контекста одной транзакции может происходить любое количество срабатываний любых тригеров любого количества таблиц. Откатить транзакцию может (по желанию разработчика) любая ошибка или условие на любом этапе выполнения.
Транзакция - это набор логически неделимых действий. И этот набор может быть сколь угодно сложным. Поэтому хаять удобный механизм before-тригеров нет оснований. В MS его нет вовсе не потому, что он не нужен.

← →
Володя Т. (2002-02-27 14:41) [53]

Да, кстати еще о транзакциях, если можно вопрос к McSimm или ко всем кто в курсе: MS SQL 2000 меня когда то сильно огорчил тем, что rollback откатывает не ту транзакцию имя которой ей указываешь, а вообще все открытые транзакции :( Избалованный автоматическими транзакциями IB я просто не знал чего делать и решил работать только в одной транзакции, безимянной. Что это было? Недоотлаженная версия MS SQL 2000 (тогда еще без исправлений) или тут есть какая-то мысль, которую я не поймал?

← →
McSimm (2002-02-27 15:42) [54]

>Володя Т. (27.02.02 14:41)
Очень похоже на мою ситуацию.
См. случай, описанный McSimm © (26.02.02 12:57)
Тогда тоже откат одной именованной открытой мною транзакции откатил изменения, сделанные другими пользователями, в других транзакциях. Для себя вывел Правило: не использовать явных транзакций на клиенте при использовании MS-SQL! Только на сервере.
В IB использование явных транзакций в клиентской программе не может привести к проблемам по определению.

← →
Romkin (2002-02-27 16:45) [55]

Ну и о чем спор?
у IB & MSSQL разный механизм синхронизации транзакций - у MS - блокирование записей, у IB - версионность... И при этом на IB транзакции не блокируют запись, даже backup просто открывает транзакцию и спокойно читает все данные из базы, при этом пользователи просто этого не замечают.
Честно говоря, я начинал знакомство с серверами БД именно с IB,
и для меня было большой неожиданностью, что MS SQL не поддерживает кучу удобных вещей, которые казались мне в IB совершенно естественными. В качестве примера можно привести IDENTITY - уж извините, но автоинкрементное поле максимально неудобно, особенно после генераторов в IB.
Насчет того, что IB не тянет большой объем/много пользователей - просто треп, есть куча примеров, и ссылки я уже давал в этом форуме.
Насчет механизмов MS SQL - вот, ИМХО, пример того, что довольно просто реазизуется в IB, попробуйте в MS SQL. Прошу прощения за большой объем, но кусок этот я просто выдрал из базы
2McSimm: мне самому интересно, как это будет выглядеть.
http://www.romkin.pochtamt.ru/exam.txt - скрипт
http://www.romkin.pochtamt.ru/readme.txt - описание
Примечание для пользователей MS SQL: в IB все триггера и вызываемые ими процедуры выполняются для каждой записи в контексте одной транзакции, которая открывается при любых изменениях данных.
2Awex: Да нет такого деления, от отчета, от данных. Данный выше кусок выдран с изменениями из реальной базы, причем любой отчет и изменения данных идут у меня за 2-10 сек при расчете заполненности за десять лет

← →
Shirson (2002-02-27 18:27) [56]

>Romkin
"В качестве примера можно привести IDENTITY - уж извините, но автоинкрементное поле максимально неудобно, особенно после генераторов в IB."

а что должно быть?

← →
Awex (2002-02-28 09:31) [57]

2Shirson

Допустим я хочу чтоб индефикаторы во всех таблицах были сквозные для всей базы ? Если в IB для этого можно использовать один генератор то какой межанизм ты посоветуешь для MS-SQL ?

← →
Romkin (2002-02-28 09:56) [58]

Наличие автоинкрементного поля обычно предполагает работу непосредственно с таблицей, как, например, в Paradox. При наличии сервера приходится считывать запись обратно или как-то еще получать значение поля, скажем, для master-detail
Генераторы делают все гораздо удобнее:
http://ib.demo.ru/DevInfo/generator.htm

← →
Bachin (2002-02-28 11:18) [59]

еще раз повторюсь:
В IB отсутствуют имнованные транзакции. И никто не заставляет Вас использовать в MSSQL. Просто это часто удобней и в IB приходится без них некоторые вещи делать через $%^&...

Но это все беспредметный спор. Если Вы не работали с MSSQL (я не имею ввиду видеть), то и не поймете этого...

Сейча я работаю с Informix и IB. Мне также не хватает многих конструкций да и других вещей, но! Те кто начинал с этой СУБД не знают об этих возможностях и абсолютно не жалеют об их отсутствии :)))

← →
Roma (2002-02-28 11:42) [60]

Отцы, это спор старый и бесконечный... "Одному нравится арбуз, а другому - свиной хрящик".
Но давайте посмотрим на вопрос с другой точки зрения. Очевидно, что все (или большинство) участвующие занимаются созданием трех-звенных распределенных клиент-сервеных систем. Т.е. можно говорить о тройке "службы_представления" - "службы_бизнеса" (среднее звено, middleware) - "службы_данных". И надо, на мой взгляд, рассматривать все в совокупности... Т.е., выделять такие тройки, которые будут оптимальны. Понятно, что все производители бьют себя в грудь (так, что молоко брызжет на стены... ;)))), мол, их системы работают со всем и вся. Это, конечно, не вранье, но все таки с чем-то какая-нибудь конкрентная система работает очень эффективно, а с чем-то - просто работает. И вот какие тройки, имхо, оптимальны и наиболее эффективны:
Visual C++ (Basic) - ADO - MSSQL
Delphi - BDE - Interbase

Oracle какое-то свое API для middleware тоже сделал, но в Oracle "чукча не писатель"... :(

← →
Shirson (2002-02-28 11:50) [61]

>Awex
"Допустим я хочу чтоб индефикаторы во всех таблицах были сквозные для всей базы ? Если в IB для этого можно использовать один генератор то какой межанизм ты посоветуешь для MS-SQL ?"

В таблицах, напротив идентификаторов отмечать галочкой пропертину Is RowGuid :)

← →
Delirium (2002-02-28 11:59) [62]

Тут кто-то заявил, что в MSSQL нельзя получить результаты хранимой процедуры в таблицу, так вот вам пример:
SELECT * INTO #Temp FROM OPENQUERY(OPEN_MASTER,"EXECUTE master..sp_help") SELECT * FROM #Temp
где OPEN_MASTER - Linked Server к самому себе.

← →
Shirson (2002-02-28 12:07) [63]

Мы так юзаем:

insert into tmp_bal
exec SProc @SDate, @FDate, "%", 0 и т.д.

Прекрасно работает.

← →
McSimm (2002-02-28 13:15) [64]

Откуда появилась мысль об отсутствии в IB именованных транзакций?

Просто механизм вложенности транзакций такой, что в использовании имен часто нет необходимости.
А так - есть. Используйте сколько хотите.

← →
SVM (2002-02-28 14:15) [65]

Вопрос: а зачем создавать временную таблицу, если можно
просто выбрать из StoredProc (как в IB).

Разумеется, для IB наиболее эффективны:
Delphi - IBO - Interbase
Delphi - IBX - Interbase

← →
Johnny Smith (2002-02-28 14:43) [66]

Я, может быть, отклонюсь от линии текущего обсуждения (хранимые процедуры, трехзвенки, временные таблицы и проч.)но вякну по теме вопроса - "IB или MSSQL".
Здесь есть два момента: а) декларируемые возможности и б) соответствуют ли они реальности. В первом случае можно разделить листик бумаги надвое и написать справа - возможности IB, а слева - возможности MSSQL. НО! Это не решит вопрос окончательно, поскольку IB глючит немилосердно в самых неожиданных местах и вот тут-то всплывает второй момент: далеко не все, что заявлено в IB, выполняется. Про MSSQL не скажу, поскольку не так много с ним работал.
Добавлю еще пару соображений: посмотрите на доли рынка СУБД, приходящуюся на ту и другую системы. Это о многом скажет. И еще сопоставьте количество разработчиков, создающих их. Насколько я знаю, в Phoenix"е, создающем FireBird их 25, а в Майкрософте - несколько сотен. И будь эти 25 конгениальными парнями, им не оскакать в качестве и объеме продукции Майкрософт.

← →
Bachin (2002-02-28 14:56) [67]

McSimm © (28.02.02 13:15)
Откуда появилась мысль об отсутствии в IB именованных транзакций?

Просто механизм вложенности транзакций такой, что в использовании имен часто нет необходимости.
А так - есть. Используйте сколько хотите.

Наконец то услышали! :)))) Плиииз ,ув. McSimm, покажите мне именованную транзакцию в Interbase.

что-то типа:
begin transaction t1
end transaction t1

← →
Deniz (2002-02-28 15:17) [68]

По поводу автоинкрементного поля в MS-SQL.
Не так давно был вопрос:"Как узнать ID вставленной записи, или как получить следующий ID на клиента перед вставкой". Точно не помню, но "нормального" варианта для MS-SQL не было.
ЗЫЖ Хотел ответить раньше (по поводу кода и ручек Bachin (26.02.02 21:21)), но Inet на работе отрубили. А сейчас вроде "остыл" уже.

← →
McSimm (2002-02-28 17:07) [69]

>Bachin (28.02.02 14:56)
>что-то типа:

Давно я в IB не писал, года 3-4. Если ошибусь - знатоки поправят:
SET TRANSACTION NAME T1 READ COMMITTED;
..statement..
COMMIT T1; - необязательно

← →
wicked (2002-02-28 17:50) [70]

2 Deniz ©

> Не так давно был вопрос:"Как узнать ID вставленной записи,
> или как получить следующий ID на клиента перед вставкой".
> Точно не помню, но "нормального" варианта для MS-SQL не
> было

insert <таблица> <что-то>
select @@identity

← →
Bachin (2002-02-28 19:02) [71]

2Deniz: прошу прощения на текст. но ведь ты получил именно то, что хотел: сделал insert, не сделал commit и читал read commited...
предотвращая следующее заявление типа "а вот IB так работает" скажу: у Oracle тот же принцип (в данном случае) что и у MS. :)

насчет ID вставленной записи: 1. влиолепно берется из inserted (в тригере) 2. по-моему есть глобальная переменная (ну нет у меня MSSQL :)

← →
vuk (2002-02-28 20:23) [72]

Я тут влезу малость. :o)
to Shirson:
>В таблицах, напротив идентификаторов отмечать галочкой
>пропертину Is RowGuid :)
Да уж... Может местами это и приемлемо, но к упорядоченной генерации идентификаторов отношения не имеет.

>insert into tmp_bal
>exec SProc @SDate, @FDate, "%", 0 и т.д.
Это-то все документировано. Гораздо интереснее было бы делать select по результатам выполнения процедуры без всяких временных таблиц. Хотя... Внутри у MS SQL много загадочного есть. Даже то, чего официально нет. :o) Например, есть там и select из процедуры (почти как в IB) но только не для всех. :o) Прикола ради зайдите в базу master и попробуйте написать:

select * from sysremote_catalogs

Много интересного будет написано в сообщении об ошибке... :o)

А правильно так :
select * from dbo.SYSREMOTE_CATALOGS < "server" >

to Bachin:
>1. влиолепно берется из inserted (в тригере)
Имелось в виду - до вставки. В MS SQL - никак. А глобальная переменная есть - @@identity. Значение ее можно получить только после вставки.

Кстати об identity. У них в MS SQL есть неприятная особенность - иногда они сбиваются (причина неизвестна), поэтому мы у себя от них отказались в пользу механизмов, похожих на generator"ы InterBase. Получается более надежно и более управляемо.

← →
TSV (2002-02-28 21:53) [73]

По поводу "сбиваются" не слышал и не видел, хотя работаю с MSSQL не первый год. Проблема автоинкремента, вернее получение его с сервера очень красиво решается с помощью ADO. Есть там такая вещь, Resync Command называется.

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

← →
vuk (2002-02-28 22:09) [74]

>По поводу "сбиваются" не слышал и не видел, хотя работаю с
>MSSQL не первый год.
Вот было как-то пару раз... После этого и отказались. Потом уже не возникало желание искать причину, поскольку проблем больше не возникало (возможно всвязи с тем, что мы identity больше не используем). Потом оказалось, что так оно надежнее с точки зрения управления генерацией идентификаторов. То есть можно для определенных случаев задавать свои правила генерации, а не просто считать от 0 и дальше. Хотя это все уже упирается в проблему искусственных ключей.

>Проблема автоинкремента, вернее получение его с сервера очень
>красиво решается с помощью ADO.
Софт уже давно пишется так, что до вставки никакие идентификаторы на клиенте не нужны. Так что не проблема это.

>Не хочу спорить из принципиальных соображений: все равно каждый
>останется при своем.
Это да. Здесь каждый выбирает то, что в его случае удобнее. В нашем оказалось удобнее использовать управляемую генерацию идентификаторов.

P.S. А с MS SQL тоже уже не первый год работаем...

← →
evgeg (2002-02-28 22:55) [75]

> Это о многом скажет. И еще сопоставьте количество разработчиков, создающих их. Насколько я знаю, в Phoenix"е, создающем FireBird их 25, а в Майкрософте - несколько сотен. И будь эти 25 конгениальными парнями, им не оскакать в качестве и объеме продукции Майкрософт.

Один гений сделает то, чего никогда не сделает сто тысяч идиотов. (Я не утверждаю, что Interbase разрабатывают гении, а MS SQL - идиоты, просто смешно слушать такие аргументы).
Кстати, почитай на досуге Брукса, чем больше разработчиков -- тем больше связей между ними, тем больше ненужной работы они делают. Один талантливый программист сделает больше, чем 10 посредственных, и ошибок у него будет меньше.

> Добавлю еще пару соображений: посмотрите на доли рынка СУБД, приходящуюся на ту и другую системы.

При чем тут доли рынка? Мы говорим о системе, а не о маркетинге. Какая человеку разница, кто кроме него пользуется этой системой? Главное, чтобы у него все работало, а от тысяч других пользователей какой ему толк, если у него система не работает как надо?

← →
AlexNord (2002-03-04 03:03) [76]

Delirium Да в принципе сравнивать можно! IB 6-й версии идет полностью бесплатный и с открытым исходником и на неограниченное количество пользователей, так что я на нем пищу и ни капли не жалею, правда задачка плёвая, но все равно! Хотя может я и не прав!:)

← →
SVM (2002-03-04 10:29) [77]

← →
Johnny Smith (2002-03-04 12:48) [78]

2SVM & 2 evgeg
На конкурсе пословиц и поговорок вы разделите 1 место :-)) Только не нужно использовать их (поговорки) как аргумент в споре. А насчет одного талантливого программиста - господа, здесь речь не о шедевре программирования, а о программном продукте, что есть разные вещи.

По существу: для "плевых" задач (2-3 клиента) IB действительно подходит, а для более или менее серьезных - MSSQL.

IB или MS SQL Server Найти похожие ветки