IB или MS SQL Server

← →
ev (2002-02-22 21:05) [0]

Сейчес работаю с IB, но думаю перейти на MS SQL Server.
Помогите определиться!
Какие отличия, плюсы, минусы?
С какими компонентами лучше работать?
Плюсы, минусы ADO?

← →
Johnmen (2002-02-22 22:09) [1]

Позволю себе замечание : 3 года назад работал под MS SQL,
потом перешел на IB, а кто-то остался под MS SQL.
Встречаясь с этими челами и обсуждая проблемы, мы приходим к единому мнению - IB это вещь, MS SQL - это как минимум большущий гимор !

← →
Aleks1 (2002-02-24 02:00) [2]

> Johnmen © (22.02.02 22:09)
А я знаю тех, кто ответит по другому.
Имхо и там и там свои плюсы и минусы. Для конкретной задачи свое предпочтение.

← →
Suntechnic (2002-02-24 06:37) [3]

>Johnmen © (22.02.02 22:09)
Я бы всё-таки был осторожней в выражениях. Эти строчки могут читать люди, которые стоят перед выбором и твоё высказывание воспримут всерьёз. А правда заключаеися в том, что для тебя это геморой, а для остальных это СУБД.

← →
sniknik (2002-02-24 08:46) [4]

Сталкивался с разными базами и могу сказать, везде есть минусы и ограничения. Про IB не знаю а MS SQL имеет больше всех (мне известных)возможностей по написанию SQL скриптов. Если работать через ADO то там где в других приходилось писать процедуры на Delphi для обработки данных или переноса то в MS SQL обходилось одним запросом или SQL процедурой (иногда даже очень больщие). Для разработчика думаю это большой плюс.
P.S. Про минусы. Знаю ощибку MS SQL изза которой даже писал в Microsoft (безуспешно). Кому интересно напишите пришлю описание и код дающий глюк (происходит при линковке dbf к MS SQL). (с обещанием ответа и описания теста)

← →
sniknik (2002-02-24 09:02) [5]

по поводу глюка. в выходные пишите на адрес niks@pupsik.ru а то с адреса в анкете все уйдет на работу и я только во вторник их увижу. (там выделенка и скачка писем на локал раз 10мин короче из дома не поймаеш)

← →
Леша (2002-02-24 09:28) [6]

А мне вот пришлось с IB перейти на SQL 2000. Выборки идут заметно быстрее. Больше понравилать политика безопасности. Ну естественно болше всяких утилит, мне, напрмер, понравилось что бэкапить базу можно по расписанию. Для IB же самому програмку писать пришлось. Более чем у IB расширенный синтаксис SQL языка. А поскольку основная логика переложена на сервер, это мне дало большие возможности. Больше возможности для оптимизации. Также проще работать c Blob полями. Вот работа с триггерами реализована намного хуже чем у IB.

← →
McSimm (2002-02-24 12:01) [7]

Минусы: После IB в MS-SQL работа с тригерами и транзакциями первое время просто невыносима.

Плюсы: Удобство и возможности администрирования, возможности TSQL богаче.

← →
AndreyGA (2002-02-25 07:36) [8]

IB - плюсы:
1) абсолютная поддержка стандартов SQL, отсюда практически не книг по IB, в MS-SQL то вместо точки нужно ставить запятую, то крестик вместо минуса или еще чего-нибудь. Все что описанов стандарте работает с пол-оборота.
2) практически не требует администрирования, есть 4 параметра, которые желательно настроить, но и без них хорошо работает.
3) легкость архивирования - 1 файл сбросил в zip (сжатие более 10 раз) на дискету (МО) и неси куда угодно
Использую для экспериментов с различными базами.
4) Малый размер - дистрибутив 25Mb из них 18 документация, в памяти в спокойном состоянии от 300К
1 файл мин. 200к.
5) Работа на многих платформах - Windows, Unix, SUN, Netware
Итог: идеальна для малых предприятий

MS-SQL - плюсы:
1) полная интеграция с Windows NT/2000, отсюда лучше политика безопасности
Минусы:
1) и главное - "изобретения" от мелкософта, не стандартные и не совместимые
2) Как всегда у Мелкософта гигантский размер СУБД 300Мб, в БД 200-300 файлов (а если один потеряется)
3) Администрирование - нужен отдельный человек.

Итог: мелкософт в своем репертуаре монополист на службе у компьютерных компаний.
http://www.az-design.ru/

← →
Fay (2002-02-25 08:10) [9]

2 AndreyGA
>IB - плюсы:
>1) абсолютная поддержка стандартов SQL
Это не совсем правда
>2) практически не требует администрирования, есть 4 параметра,
>которые желательно настроить, но и без них хорошо работает.
Это не достоинство, а следствие ограниченых возможностей
>3) легкость архивирования - 1 файл сбросил в zip (сжатие более
>10 раз) на дискету (МО) и неси куда угодно
может ли вызвать сложности архивирование 2-х файлов?
>4) Малый размер - дистрибутив 25Mb из них 18 документация
Малый размер дистрибутива не может являться достоиством СУБД
>Итог: идеальна для малых предприятий
Ничто не идеально

>1) и главное - "изобретения" от мелкософта, не стандартные и не
>совместимые
С чем не совместимые? С PL/SQL или Photoshop-ом?
>2) Как всегда у Мелкософта гигантский размер СУБД 300Мб,
300 Mb - маленькая база, но не каждая база достигает этого
объёма.
>в БД 200-300 файлов
Ты хорошо посмотрел? Меньше 2-х не выйдет, но чтобы 200!
Проверь - похоже ты преувеличил, а если нет - значит так было
нодо.
>(а если один потеряется)
А если сервак потеряется?
>3) Администрирование - нужен отдельный человек.
Не обязательно потребуется брать на работу специалиста,
но если этого потребует ситуация - и под IB наймёшь.
>Итог: мелкософт в своем репертуаре монополист на службе у
>компьютерных компаний.
...А в компаниях сидят слабоумные дети, не способные
самостоятельно выбрать. Ужас.

← →
Yavfast (2002-02-25 09:35) [10]

Существенное отличие - цена.
IB можно использовать на халяву, а за MSSQL надо платитькругленькую сумму.

← →
solsoft (2002-02-25 10:38) [11]

Здравствуйте!
Мы много лет успешно работаем на IB - не жалуемся, всё быстро и надёжно!...
Однако, проводили эксперименты по скорости обработки
различных SQL-запросов на IB и на MS SQL.
Выводы:
1 Порядка неск. сот тысяч записей IB быстрее. Да и вообще,
на малых базах нет смысла городить MS SQL.
2 Где-то к миллиону-двум позиция выравнивается.
3 А далее - MS SQL выигрывает НА ПОРЯДОК (т.е. в 10 и более раз!)

Ну, а что касается администрирования, сложности встроенного языка для хранимых процедур и проч. - всё правильно, MS SQL посложнее будет. Но ведь и DOS проще, чем Windows - и что?

← →
}{unter (2002-02-25 11:00) [12]

Да но есть ещё альтернатива бесплатный MSDE для всех платформ !
Абсолютно тотже MSSQL только в кастрированном варианте по количеству подключений и скорости обслуживания этого большого (больше 5) количества подключений !

← →
Dimedrol (2002-02-25 11:38) [13]

К стати, разве не является БОЛЬШУЩИМ плюсом то, что ИБ работает под Линухом, и имеется в OpenSource варианте ?!
По-моему - бесспорно !

← →
AlexanderB (2002-02-25 12:38) [14]

MS SQL - для "больших" коммерческих структур.
Если компания небольшая и данных относительно немного - Interbase.
И та и другая впоследствии обрастают ... и требуют администрирования.
Я, например, изначально использовал обе.
Очень быстро внедрил Interbase, но остановиться пришлось на MS SQL.

← →
MetallAdm (2002-02-25 13:26) [15]

Не знаю года 4-5 (непомню) сидим на MS SQL
пока некаких проблем небыло !
А базо то полнеет с каждым днем !!

← →
Delirium (2002-02-25 14:35) [16]

Почитал я рассуждения некоторых - возмущению нет предела, как вообще можно сравнивать MSSQL и IB?
MSSQL vs ORACLE - это мне понятно,
IB vs ACCESS - то-же понятно, но MSSQL vs IB - это нонсенс !

IB - СУБД для небольших организаций, 20-50 клиентов.
А MSSQL это настоящая пробышленная СУБД, количество клиетнов тут исчисляется сотнями, а кое-где и тысячами. MSSQL подерживает множество сложнейших механизмов репликаций, и ориентирован на многосерверную работу и распределённые БД.

Надо понимать, что в небольших организациях MSSQL используют из-за его уникальной масштабируемости и удобства, а не потому, что он - равный конкурент СУБД типа IB или ACCESS.

Таково моё мнение.

← →
[NIKEL] (2002-02-25 15:38) [17]

2Delirium
не скажи, давно известно что IB недавно появилась на Российской сцене(сравнительно с 1993 года) - и почему же? Широкое
применение InterBase в правительственных структурах и военно-
промышленном комплексе США было преградой на пути продвижения InterBase в Россию. Среди целого ряда крупных реализаций систем на InterBase в России можно выделить Межбанковскую Валютныю Биржу ММВБ, Центр Управления Полетами ЦУП, внешнеторговую корпорацию Авиаэкспорт и др.
кто там говорил на счет как можно сравнивать??? и что эта субд для небольших предприятий???
ведь надо понимать, что реализация огромной информ. системы включает в себя как миниум не один сервер СУБД, а десятки и сотни которые работают сообща
...подумайте над этим

← →
Bachin (2002-02-25 16:13) [18]

2Delirium : спасибо, что написал мои мысли - руки не доходили :)
а насчет примеров - это не показатель. некоторые перешли на MySql - ну и что? если кто-то скажет что для бизнес-логики в двухзвенке может быть SQL сервер без тригеров, то ... лично мне будет смешно.
Также веселят доводы по поводу простоты администрирования! "У IB четыре параметра, да и те можно не настраивать"... и в MSSQL можно не настраивать и в Oracle, только работать чуть хуже будет :))
а меня например пугает отсутствие логов транзакций!
и самое интересное: знатоки IB так нелюбящие MSSQL покажите мне кусочек кода, который я не смогу перенести на MSSQL БЕЗ выкрутасов.
Мне, например, сейчас, работая с IB, не хватает многих вещей...
(про администрирование я вообще мочу! его НЕТ)

← →
Delirium (2002-02-25 16:38) [19]

> [NIKEL]
Уж не утверждаешь-ли ты что IB более распространён чем MSSQL?
А на счёт "огромной информ. системы", так ведь я об этом и говорю, MSSQL как раз и подходит для крупномасштабных решений. А если какие-либо структуры в Росии предпочитают IB, то могу тебя уверить в нашей "дикой" стране далеко не всегда разворачиваются полномасштабные исследования в вопросах выбора средств, даже в оч.крупных организациях (я работал и работаю сейчас как раз в такой). А уж тем более в государственных, по моему опыту тут всё решают деньги, а не функциональность той или иной СУБД. Так что если ЦУП или ММВБ выбрали IB, это отнюдь не значит что он чем-то лучше, скоре он просто дешевле обошёлся в данных случаях, или кто-то из руководства нагрелся на этом.

← →
[NIKEL] (2002-02-25 16:56) [20]

2Delirium
неутверждаю
>>на счет что кто то нагрелся
не думаю что это так, а думаю что там работают люди которые умеют по настоящему настраивать ситему
и ты думаешь что в таких организациях стоят Win сервера??? ты ошибаешься

← →
Delirium (2002-02-25 17:01) [21]

> [NIKEL]
А почему-же тогда такие "умные" не выбрали Oracle ?

← →
McSimm (2002-02-25 17:04) [22]

>знатоки IB так нелюбящие MSSQL покажите мне кусочек кода,
>который я не смогу перенести на MSSQL БЕЗ выкрутасов.
Я не поклонник IB и не противник MS-SQL. Работаю на MS-SQL уже несколько лет. Но вынужден повториться:
- механизм транзакций в MS-SQL отвратительный. Слабый (по возможностям) и неудобный (в программировании).
- Очень не хватает IB-механизма триггеров. То, что в Interbase делается легко и просто в триггере, в MS действительно приходится реализовывать с помощью выкрутасов.

Мнение субъективное, но не только мое.

← →
Delirium (2002-02-25 17:08) [23]

> McSimm
"То, что в Interbase делается легко и просто в триггере, в MS действительно приходится реализовывать с помощью выкрутасов."
- а можно примерчик ?

← →
McSimm (2002-02-25 17:39) [24]

Реальный пример приводить - долго объяснять. Поверьте, на практике сталкивался не раз.

- в MS-SQL невозможно в тригере следить за уникальностью записи для UNIQUE индекса.
- inserted - доступна только для чтения, в отличие от NEW в Interbase.
- Вызов BEFORE и AFTER - раза два могло бы очень облегчить мне участь.
- Активация/деактивация тригера, если не ошибаюсь, в IB делается крайне просто.
- Приоритетность срабатывания тригеров - несколько раз очень нужно было.

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

← →
Delirium (2002-02-25 17:57) [25]

> McSimm
По пунктам:
"в MS-SQL невозможно в тригере следить за уникальностью записи для UNIQUE индекса." - не ясно что ты под этим понимаешь, получение значения Identity или что?

"inserted - доступна только для чтения, в отличие от NEW в Interbase." - а зачем тебе писать в inserted, когда надо писать в саму таблицу, опираясь на данные из inserted?

"- Вызов BEFORE и AFTER - раза два могло бы очень облегчить мне участь." - совершенно не понятно чем, если есть те-же таблицы inserted и deleted?

"- Приоритетность срабатывания тригеров - несколько раз очень нужно было." - sp_settriggerorder

← →
McSimm (2002-02-25 18:05) [26]

Спор этот ни к чему не приведет :) Я же говорил, что все можно сделать, уже несколько лет пишу на MS-SQL, IB забыл совсем.

По пунктам:
1. Если происходит нарушение уникальности ключа при добавлении/изменении, в MS - до тригера дела не дойдет, в IB можно эту ситуацию обработать. Я не говорю, что это необходимо, но были очень красивые решения некоторых проблем.

2. BEFORE и AFTER это не OLD и NEW - это тип триггера, время его срабатывания - до или после события.

3. Спасибо за информацию, посмотрю.

← →
Delirium (2002-02-25 18:16) [27]

Хм, по поводу №1 - ситуация исключительная и тут триггера и недолжны работать, надо обрабатывать откат транзакции;
№2 - триггера, которые работают до завершения транзакции, это нарушение логики постоения БД: триггер - должен ВСЕГДА подтверждать транзакцию, а никак не иначе.

← →
ev (2002-02-25 18:20) [28]

2 McSimm © (25.02.02 17:04)
> механизм транзакций в MS-SQL отвратительный. Слабый (по
> возможностям) и неудобный (в программировании).
по-подробней можно...

> Очень не хватает IB-механизма триггеров. То, что в Interbase
> делается легко и просто в триггере, в MS действительно
> приходится реализовывать с помощью выкрутасов.
Что в MS-SQL нет механизма триггеров.

← →
Andreym999 (2002-02-25 19:58) [29]

Немножко не по теме, но когда я работал в госказначействе то от днепропетровских коллег я услышал следующее утверждение:
Oracle выигрывает у MS SQL по скорости только, на очень больших базах данных. а на базах в несколько Гб MS SQL значительно быстрее. Следует отметить что объемы информации в днепропетровской области хм весьма не маленькие ... мягко сказано. Поэтому IB здесь вообще не конкурент на мой личный взгляд. А поэтому этот спор считаю немного неккоректным. Для каждого сервера существует своя ниша и свой круг решаемых задач, и все зависит только от типа решаемых задач, а не утверждений типа Oracle рулез MS SQL отстой Linux forever Windows must die. Но поклонникам и настоящим специалистам MS очень повезло потому что решения этой компании, не смотря на всевозможные баги MS, позволяют строить очень технологические и красивые системы с красивыми решениями. Хотя бы связка IIS+ASP+MSSQL. Или VB+VC.
То чего я не увидел пока продукции ни одной компании. Хотя я большой поклонник Borland. Вот так. ;)

← →
Tonie (2002-02-25 20:20) [30]

На самом деле я конечно согласен, что для каждой задачи - свое решение, но вот такие вещи все же раздражают:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms02-007.asp
А о "красоте" IIS или ASP я бы осторожнее высказывался

P.S. Это не значит, что я с перекошенным лицом ору: "Must die!!!" :-), я собственно сам с продуктами от ms дело имею, но отношение к ним "Прохладно-настороженное"

← →
Deniz (2002-02-26 07:40) [31]

>Bachin (25.02.02 16:13)
>и самое интересное: знатоки IB так нелюбящие MSSQL покажите
>мне кусочек кода, который я не смогу перенести на MSSQL БЕЗ
>выкрутасов.
Ну почему так нелюбящие MSSQL, просто есть некоторые ... неровности.
По поводу примера, реализуй БЕЗ выкрутасов:
1. POST EVENT "Test Message".
2. Выбор идент-а на клиента(в MS-SQL есть последовательности, но много слышал, что они ... ).
А про минусы могу сказать следующее(сам пробовал), Delphi -> xxxQuery(кеширование) + UpdateSQL. Кусок кода:
DataBase.StartTransaction; Query1.Edit; ... Query1.Post; Query1.ApplyUpdates; ... -> Lock table DataBase.Commit;
После Apply и до Commit -> Lock table для всех других пользователей, даже для просмотра. Хм???
Скажите где ошибка? (без проверки на ошибки, все вводится правильно и исключений нет).

← →
maratFromTomsk (2002-02-26 07:50) [32]

Что я могу сказать про IB - он мне нравится.
во первых он простой, и в то же время мощный.
сть у него некоторые проблемы, например такие что его производительность
начинает со временем падать и его надо периодически
backup & restore.

Мы одновремено работаем над двумя версиями программ под Оракл и IB.

при переходе на Оракл нам не хватало некоторых возможностей IB.

таких как например выборка из хранимой процедуры
я например таким образом делал
сворачивание сальдо в дебетовую или кредитовую сторону
в хранимой процедуре,
а параметры использовал для фильтрации требуемых данных.

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

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

В Оракл есть ограничения
нельзя делать выборки из функций,
в функциях используемых в запросах нельзя изменять данные
или использовать внешние переменные.

Хотелось бы знать есть ли такая же возможность в ms sq.

или возможность делать подзапросы в секции полей
select a.id,
(select b.name from t1 b where b.id = a.id) as bname,
(select c.name from t2 c where b.id = a.id) as cname
from tmain a

это есть очень хорошо и удобно.

Марат

← →
Deniz (2002-02-26 08:11) [33]

>Delirium © (25.02.02 18:16)
>№2 - триггера, которые работают до завершения транзакции, это
>нарушение логики постоения БД: триггер - должен ВСЕГДА
>подтверждать транзакцию, а никак не иначе.
А причем здесь транзакция? Триггер это набор некоторых действий, которые выполняются до/после изменения(insert, update, delete) таблицы. А транзакцию уже пользователь завершает по кнопкам сохранить/отменить(может не так хорошо выразился, но думаю меня поймут).

← →
evgeg (2002-02-26 08:17) [34]

> IB vs ACCESS - то-же понятно, но MSSQL vs IB - это нонсенс !
Ты не прав. IB может работать и с сотнями клиентов, это настоящий sql-сервер. То, что MSSQL сам по себе занимает большой объем, а IB -- маленький, говорит наоборот в пользу IB.

← →
Толик (2002-02-26 09:32) [35]

Я вот почитал, но так и не понял, что человеку выбрать? Если он все-таки, выберет IB, то я так понял, у него будут проблемы при большом объеме БД. Непонятно вот что - в этом случае ему все-равно придется перейти на SQL или Oracle. Или у IB есть будущее?

← →
MetallAdm (2002-02-26 11:22) [36]

Странно !
много интерстного но все же сдесь присутсвуют нотки вкуса ....
В принципе оно так и есть пока сам не попробуешь
не узнаешь все приходит с опытом
а вот там исходя из своего опыта уже и можно решить
что лутше что хуже
ведь каждому ближе что то свое !

← →
FFFF (2002-02-26 11:40) [37]

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

← →
Dok_3D (2002-02-26 12:21) [38]

Есть старая истина (ну... почти истина),
что дороже, то и лучше.
Если MSSQL стоит 20000$ на один процессор, а IB вообще ничего не стоит, то конечно MSSQL лучше :))).

P.S. А вообще, согласен с теми, кто утверждает, что это пустые споры.

← →
ev (2002-02-26 12:22) [39]

1. справиться IB с ОЧЕНЬ большим объемом данных?
2. как по безопасности IB?

← →
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 Найти похожие ветки