MS SQL Server 7.0 vs Interbase

MS SQL Server 7.0 vs Interbase

• Keith Gilbert, Labor Ready

• • У меня сейчас нет времени на подробный комментарий, но есть несколько причин, по которым я продолжаю работать с IB Database (мы посмотрели и протестировали MS SQL Server 7 Beta 2). Приведенные пункты не являютс точным сравнением, потому что MS SQL Server 7 все-таки имеет некоторые изящные решения. Я просто приведу причины, по которым для нас выбор IB Database остается лучшим:
    • (a) Механизм многоверсионности записей- IB Database очень хорошо подходит *ОДНОВРЕМЕННО* как для OLTP систем так и для длительных запросов благодар механизму многоверсионности. В SQL Server 7 все равно остаются проблемы с блокировками (как и с блокировками на уровне записей в SQL Anywhere) когда вы запускаете длительные запросы и одновременно вставляете записи. С MS SQL Server 7 это нормально не работает.
    • (b) Размер: Даже если MS SQL Server 7 будет работать на Win 95 (а вы знаете что для работы Beta 2 *ТРЕБУЕТСЯ* установленый Internet Explorer 4.01 Installed????), все-равно это тяжелая система. Мастер-таблицы слишком огромные. Мне удалось урезать объем, занимаемый MS SQL Server 7 до 80 MB, однако это гораздо больше чем требуется для IB 5
    • (c) UDF - SQL Server может вызывать DLL, но я не думаю что реализация являетс такой-же быстрой как способ вызова DLL в IB (в общем UDFs работают быстрее с меньшими накладными расходами)
    • (d) Надежность: Вы *должны* помнить что SQL Server 7 по существу продукт версии 1.0!!! Он *не* содержит кода от Sybase, и был переписан практически "с нуля". Я не буду использовать для работы такой сервер, пока для него не появится сервиспак хотя-бы версии 2 (наверное через год)
    • (e) Log-файлы - Некоторым нравится управлять раздельными файлами Log-ов, но не мне. Для меня IB Database является очень легкой в сопровождении, и меня не заботит что там за куча непонятных файлов на диске. SQL Server 7 не страдает малым количеством файлов, и администратору достаетс намного больше забот, чем с IB
    • (f) Каскадная ссылочная целостность - IB Database 5 сейчас поддерживает полный синтаксис DRI, а SQL Server 7 - нет.
    • (g) VarChar - IB Database обрабатывает поля VARCHAR (особенно длиной более 2k) намного лучше чем SQL Server вообще способен. SQL Server 7 работает лучше чем раньше, но IB превосходит его в этом плане
    • (h) Многоплатформенность - То, что я могу без проблем перенести базу данных с NT или Win 95 на Unix или Linux - просто отлично. Если NT сдерживает производительность (или вы замучились перегружать сервер), то переходите на Unix или Linux . Особенно, если вы слышали что NT плохо масштабируетс при увеличении процессоров (Unix-ы с этим проблем не имеют).
    • (i) Сопровождение - я установил наше ПО (написаное на Delphi 3/ Interbase) во всех региональных офисах нашей компании (более чем 400) этим летом (бета-тестирование проходило в ~300-х офисах), и наша компания очень довольна производительностью и легкостью сопровождения.

• Dmitry Kuzmenko, Epsylon Technologies
  • Hello, Keith!
  
  
  • Keith Gilbert wrote:
    > Надежность: Вы *должны* помнить что SQL Server 7 по существу продукт версии
    >1.0!!! Он *не* содержит кода от Sybase, и был переписан практически "с нуля". Я не
    >буду использовать для работы такой сервер, пока для него не появитс сервиспак
    >хотя-бы версии 2 (наверное через год)

    Один мой знакомый после просмотра 7.0 пришел к выводу что это не совсем версия 1.0 - достаточно много файлов, которые те-же самые что и в 6.5, и есть масса "старых особенностей", которые были в 6.5 (а при условии полного переписывания должны были быть исключены). Не могу, правда, утверждать что 7.0 <> 1.0, но может-быть есть кто тщательно сравнивал?

• Keith Gilbert, Labor Ready
  • >> Один мой знакомый после просмотра 7.0 пришел к выводу что это не совсем версия 1.0
  
  
  • Может быть... а может и нет. Я не знаю, были-ли переписаны утилиты или программы управления, но Микрософт утверждает что ядро СУБД - да, переписано. (иначе как-бы они реализовали блокировки на уровне записи и другие новые возможности)

• Fred Wilson, SE Bell+Howell Cope Company
  • MSSQL Server работает быстрее ? Весьма сомнительно. Мы разрабатываем базу данных "реального времени" для обработки большого количества почты. Что я имею в виду под "реальным временем":
    • - У нас два (2) типа компьютеров. Один обрабатывает около 12 тыс. счетов в час, другой - около 18 тыс. счетов в час.
    • - Каждого тип компьютера читает от 800 до 1100 байт данных из базы данных, необходимых для каждого счета (несколько объединенных таблиц), и записывает около 200 байт данных для каждого обработаного счета.
    • - Это транслируется в 6 обращений к БД в СЕКУНДУ для типа 12 тыс. (3 чтени и 3 записи), и в 10 обращений к БД в СЕКУНДУ для каждого компьютера типа 18 тыс. ( 5 чтений and 5 записей).
  • Мы тщательно протестировали на время отклика MS SQL версии 6.5, IB версии 4.2 и IB версии 5.0. Мы наняли 2-х консультантов (оба Microsoft Certified "Product Specialist" и Microsoft Certified "Solution Deveopers") чтобы они помогли нам в настройке MS SQL, программировании, разработке БД, тестировании и замерах. Все тестирование и замеры IB выполнял я, параллельно с тестированием MS SQL. (Это было 6 месяцев назад, тогда я вообще ничего не знал об IB).
  
  
  • Оба сервера работали на одинаковых компьютерах - Dual PII 200, 128 mg RAM, 4 GIG Wide SCSI III drive, NT Server 4.0 SP3. Клиентами являлись компьютеры с WIN95, в основном P166, 64 meg RAM, 2 GIG IDE HD. Сеть работала через TCP/IP на 10MBS.
    MS SQL не смог "тянуть" более 10 клиентских компьютеров типа 12K одновременно. IB нормально обрабатывал 25 12K компьютеров или 20 18K компьютеров.
    Настоящей проблемой с MS SQL была борьба с блокировками. Не говор уже о transaction log.
    Я работал с MS SQL пять лет назад (1 из консультантов был из той компании) в течение 3-х лет. Много кодирования, о котором как оказалось можно даже не думать при использовании IB.
    Мы выиграли очень много, выбрав IB вместо MS SQL (инструменты для программировани клиентских мест, квалификация разработчиков, и т.п.), в частности скорость, удобство, и т.п. IB оказался намного лучшим выбором из двух. MS SQL был не просто медленнее чем IB, а откровенно "тормозил".
    При переходе на IB 5.0 мы получили увеличение производительности на ~10-20 % по сравнению с IB 4.2.

• Fred Wilson, SE Bell+Howell Cope Company
  • > Вы тестировали версию 7.0?
  
  
  • Нет, MS SQL V7.0 мы не смотрели. Сейчас было принято окончательное решение остаться на IB, и у нас нет времени опять писать тестовые программы и вообще тестировать. Разве только при какой-то катастрофической ситуации с IB мы сделаем это..
    Немного дополнений к этой "истории", для тех кому интересно.
    Два разных типа компьютеров с которыми мы работаем, различаются как программно так и аппаратно. Компьютеры типа 12K являются клиентами с пользовательским интерфейсом и обращаются к IB на NTS4.0. Компьютеры типа 18K работают под SCO Unix, также обеспечивая интерфейсную часть для пользователя. Сервером для них также является IB на Intel NTS4.0. Когда мы работали с MS SQL, было очень много идей как машины со SCO будут работать с NT4.0 (где работал MS SQL). Главной идеей был DCOM, но его тогда не было для SCO !. Сейчас, кажется, AGSoft выпустил DCOM для SCO...
    Так или иначе, мы решили писать приложения на IB API и C++. Мы (Cope Company part of Bell+Howell) написали некий CDK (Client Developers Kit) на C++. Остальной части компании, Bell+Howell group (компьютеры типа 18K, со SCO), пришлось просто перекомпилировать C++ CDK, при помощи компилятора SCO GNU C++, приобрести IB developers kit (API lib) для SCO, и ,уфф.. натуральное волшебство! Компьютеры 12K (NT4.0) и 18K (SCO) могут работать с сервером IB на NT4.0.
• David Zvekic
  • В июньской версии DBMS появился обзор MSSql..
  
  
  • И вот что я обнаружил:
  • • Вы можете использовать более одного триггера на оператор DML, но все-равно это только триггеры типа AFTER. (IB и Oracle имеют триггеры как BEFORE так и AFTER, но IB не упомянули).
    • Можно использовать страницы размером до 8К, однако нужно быть осторожным, т.к. оптимизатор может сделать эскалацию блокировки на уровне страницы, в результате вы получаете блокировки страницами по 8К, а не по 2К как раньше
    
    
    • Эту проблему можно обойти явно включив блокировку на уровне записи при помощи новой опции ROWLOCK. Причем MS SQL теперь сам расширяет количество блокировок, если это необходимо. Т.е. вы теперь не будете получать сообщение OUT OF LOCKS как раньше (или вы можете вообще забыть о блокировках если работаете с IB).
    • Читающие транзакции все-таки блокируют пишушие транзакции (в отличие от Oracle и Interbase, IB опять не упомянули), но вы можете использовать уровень изоляции DIRTY READ и READPAST (который пропускает блокированные записи) для того чтобы обойти это ограничение. Разумеется, такое решение годитс если вы согласны получать неверные данные, но я думаю что лучше получать хоть какие-то данные чем вообще их не получать (или вы можете работать с IB, у которого нет таких проблем вообше).
    • Каскадной декларативной ссылочной целостности нет, такой как в Oracle и Interbase (и опять совсем не упомянули IB).
    • Вы можете модифировать триггеры и процедуры, сохраняя текущие взаимизависимости и права (прямо как в IB). И вы даже можете создавать процедуры, которые ссылаются на несуществующие таблицы. Я думаю что они взяли это из Visual Basic, где можно писать процедуры, которые ссылаются на несуществующие переменные.
• David Zvekic

  
  Если вас устраивает чтение некорректной информации из БД, то тогда DIRTY READ действительно можно использовать. Лично мне кажется что реально DIRTY READ использовать нельзя.
  READPAST также полезен как и DIRTY READ, т.е. фактически непригоден для нормальной работы с данными

  Оба этих режима являются всего-лишь хакерскими приемами для обхода недостатков MS-SQL.

  • >DIRTY READ можно использовать в большинстве ситуаций, но хотелось-бы получить объяснения по поводу READPAST.