| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
IB или MS SQL Server [D6]
ev © (2002-02-22 21:05:00)Сейчес работаю с IB, но думаю перейти на MS SQL Server.
Помогите определиться!
Какие отличия, плюсы, минусы?
С какими компонентами лучше работать?
Плюсы, минусы ADO?
Romkin (2002-02-28 09:56:00) [21]Наличие автоинкрементного поля обычно предполагает работу непосредственно с таблицей, как, например, в Paradox. При наличии сервера приходится считывать запись обратно или как-то еще получать значение поля, скажем, для master-detail
Генераторы делают все гораздо удобнее:
http://ib.demo.ru/DevInfo/generator.htm
Awex (2002-02-28 09:31:00) [22]2Shirson
Допустим я хочу чтоб индефикаторы во всех таблицах были сквозные для всей базы ? Если в IB для этого можно использовать один генератор то какой межанизм ты посоветуешь для MS-SQL ?
Shirson (2002-02-27 18:27:00) [23]>Romkin
"В качестве примера можно привести IDENTITY - уж извините, но автоинкрементное поле максимально неудобно, особенно после генераторов в IB."
а что должно быть?
Romkin (2002-02-27 16:45:00) [24]Ну и о чем спор?
у 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 сек при расчете заполненности за десять лет
McSimm (2002-02-27 15:42:00) [25]>Володя Т. (27.02.02 14:41)
Очень похоже на мою ситуацию.
См. случай, описанный McSimm © (26.02.02 12:57)
Тогда тоже откат одной именованной открытой мною транзакции откатил изменения, сделанные другими пользователями, в других транзакциях. Для себя вывел Правило: не использовать явных транзакций на клиенте при использовании MS-SQL! Только на сервере.
В IB использование явных транзакций в клиентской программе не может привести к проблемам по определению.
Володя Т. (2002-02-27 14:41:00) [26]Да, кстати еще о транзакциях, если можно вопрос к McSimm или ко всем кто в курсе: MS SQL 2000 меня когда то сильно огорчил тем, что rollback откатывает не ту транзакцию имя которой ей указываешь, а вообще все открытые транзакции :( Избалованный автоматическими транзакциями IB я просто не знал чего делать и решил работать только в одной транзакции, безимянной. Что это было? Недоотлаженная версия MS SQL 2000 (тогда еще без исправлений) или тут есть какая-то мысль, которую я не поймал?
McSimm (2002-02-27 11:54:00) [27]>Володя Т. (27.02.02 11:33)
Спасибо. Я именно об этом.
При этом вложенность транзакций настоящая, а не savepoints. Если не ошибаюсь, все данные в IB представимы по версиитранзакции - уникальное растущее значение. Отличный механизм.
К слову - я не вступил в спор относительно тригеров, которые якобы обязаны завершать транзакции и пр. только потому, что все эти утверждения совершенно безосновательны.
Внутри контекста одной транзакции может происходить любое количество срабатываний любых тригеров любого количества таблиц. Откатить транзакцию может (по желанию разработчика) любая ошибка или условие на любом этапе выполнения.
Транзакция - это набор логически неделимых действий. И этот набор может быть сколь угодно сложным. Поэтому хаять удобный механизм before-тригеров нет оснований. В MS его нет вовсе не потому, что он не нужен.
Володя Т. (2002-02-27 11:33:00) [28]
> McSimm © (27.02.02 10:51)
> Уже не помню как в IB, но помню, что это было очень красиво
> и лаконично.
Если можно, постараюсь напомнить: в IB вообще ничего кроме полезного кода в этом случае можно не писать. В случае неудачи возникнет exception недостаток которых в MS я сильно переживал. rollback писать не надо, он сам произойдёт, да и commit в случае транзакции по умолчанию тоже излишен.
McSimm (2002-02-27 10:51:00) [29]>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.
Ну это явно перебор. Причем в противоположную сторону
DSR (2002-02-27 08:58:00) [30]IB
MSSQL
evgeg (2002-02-26 22:37:00) [31]> что дороже, то и лучше.
Чушь. Не верится, что есть люди, которые могут так думать по настоящему.
> Поднимите руки те, кто правил исходники ИБ?
Здесь ты таких людей, может, и не найдешь, а вот на ib.demo.ru их полно.
> 1. справиться IB с ОЧЕНЬ большим объемом данных?
Какой объем данных ты считаешь очень большим? C сотнями терабайт надо брать Oracle.
> 2. как по безопасности IB?
А что нужно то? Чем MS SQL безопаснее?
Bachin (2002-02-26 21:21:00) [32]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 НЕТ именных транзакций. Если это не правда - покажите плиииз ооочень нужны...
Кулюкин Олег (2002-02-26 17:41:00) [33]2 Dimedrol ©
> К стати, разве не является БОЛЬШУЩИМ плюсом то, что ИБ работает под Линухом, и имеется в OpenSource варианте ?!
> По-моему - бесспорно!
Поднимите руки те, кто правил исходники ИБ?
В реальной жизни кому-либо его OpenSource"овость пригодилась?
По личным ощущениям отдаю преимущество MS SQL.
Его минусы - нужна более мощная машина нежели для ИБ. Посложнее администрировать (это не смертельно).
Плюсы - большие возможности SQL.
Стабильно работает с большими объемами данных.
Awex (2002-02-26 15:48:00) [34]В этой бесседе потерялась одна нить, это как спроектированнна база. То есть какой подход быль использован.
Существует 2 типа построения базы:
1. От отчета
2. От данных.
И напрасно требовать быстрого построения отчета от базы спроектированной по 2 принципу. Нужно сразу проектировать базу на максимальную скорость получение отчета.
McSimm (2002-02-26 15:04:00) [35]Я бы такой итог не подвел.
Почему плохо работает? Хорошо работает.
Есть определенная специфика. К чему-то надо привыкнуть, с чем-то смириться, чего-то избегать.
Тому кто с IB не был знаком до MS-SQL - вообще хорошо :)
Delirium (2002-02-26 15:03:00) [36]> Deniz
"А причем здесь транзакция? Триггер это набор некоторых действий, которые выполняются до/после изменения(insert, update, delete) таблицы. А транзакцию уже пользователь завершает по кнопкам сохранить/отменить" - каждое "изменение" и есть минимальная тразакция, и триггер активирутся только после успешного её завершения. Как ты представляешь себе триггерную целосность если была бы возможность в триггере откатить или модифицировать вызвавшую его транзакцию? Триггеры работают исключительно с результатами работы транзакций, и в свою очередь, могут модифицировать эти результаты. Таким образом, аргумент (в контексте вышео значенного спора с McSimm) в пользу before триггеров - это просто уловка, как я понимаю, для обхода декларативной целостности, что собственно её и нарушает. Именно по этому в MSSQL этого нет и не надо.
ev (2002-02-26 14:52:00) [37]Т.е. подведя итог всему сказанному, можно сказать: пользуйся IB, хотя MS SQL - лучше, но плохо работает!
Я правильно понял?
Володя Т. (2002-02-26 13:11:00) [38]А мне вот задачку год назад довелось решать :) Надо чтобы все написанное за 5 лет в IB работало и в MS, и чтобы exe-файл один был для все равно какой СУБД. Получил удовольствие от ее решения :)
McSimm (2002-02-26 12:57:00) [39]>ev © (25.02.02 18:20)
Мне сейчас трудно ответить, разложив по полочкам - это накопленное отношение. Например в IB очень легко (насколько помню) организовывается транзакция в стиле
try
любая работа
except
rollback-exit при любой ошибке
end
commit если небыло ошибок
- В MS-SQL во многих процедурах мне пришлось писать некрасивый код после каждой команды. - Процедура на 60% состоит из проверки на ошибку и принятия решения commit-rollback
- Вложенность какая-то ненастоящая.
- Открывая транзакцию приходиться гадать, а где же она закроется? Во вложенном вызове процедуры или в тригере каком?
- Однажды у меня из-за глюка осталась открытая транзакция (открыл по глупости из клиентского приложения). В конце дня каким-то образом база сделала rollback этой транзакции (по-видимому в результате backup операции). Так из базы пропала почти вся информация добавленная в нее после открытия транзакции.
База буквально откатилась к утреннему состоянию. Но не полностью, а какими-то загадочными участками. (Некоторые справочники сохранили информацию)
При этом дневная работа не имела к этой транзакции прямого отношения - разные пользователи, разные компьютеры.
В IB откат транзакции откатит только то, что выполнено в ее контексте
>Что в MS-SQL нет механизма триггеров.
Есть, но не такие удобные.
ev (2002-02-26 12:22:00) [40]1. справиться IB с ОЧЕНЬ большим объемом данных?
2. как по безопасности IB?
| |
Страницы: 