В чём преимущества MSSQL2000 над IB6X(FB1.5.X)?

← →
vitv © (2007-01-31 09:32) [0]

← →
Sergey13 © (2007-01-31 09:38) [1]

А недостатки ты уже знаешь?

← →
vitv © (2007-01-31 09:47) [2]

Нет. Просто интересно Мастеров послушать. Одно дело документация, другое дело люди, имеющие опыт работы.
Я с MSSQL2000 не работал.

← →
Sergey13 © (2007-01-31 10:01) [3]

> [2] vitv © (31.01.07 09:47)

Это просто разные продукты по масштабам и сравнивать их несколько некорректно. МС - это сервер уровня предприятия и выше, ИБ - уровень рабочей группы.
ИМХО.

← →
pasha_golub © (2007-01-31 10:03) [4]

> В чём преимущества MSSQL2000 над IB6X(FB1.5.X)?

Выговаривать легче.

А если серьезно, согласен с
> Sergey13 © (31.01.07 10:01) [3]

← →
vitv © (2007-01-31 10:08) [5]

Ясно.

← →
Kostafey © (2007-01-31 10:13) [6]

> [3] Sergey13 © (31.01.07 10:01)

В букварях пишут, мол MS SQL Server- штку масштабируемая, и для предприятия и для ползователькой машины.

← →
Sergey13 © (2007-01-31 10:20) [7]

> [6] Kostafey © (31.01.07 10:13)

У МССКЛ-я, насколько мне известно, есть разные версии, в том числе и для десктопного применения. В сабже упоминается вроде как основная версия.
Впрочем я МС-серваком знаком очень поверхностно.

← →
Skyle © (2007-01-31 10:51) [8]

Плюс ко всему MSSQL 2000 блокировочник, а IB, насколько я знаю, версионник, так что есть особенности.

← →
tesseract © (2007-01-31 10:58) [9]

> Впрочем я МС-серваком знаком очень поверхностно.

FB вообще-то нормально себя чуствует и при нагрузке уровня предприятия. Микрософт же наняла главного разработчика FB для работы над MS SQL.

Из недостатков - относительно труден в настройке баз и прав пользователя.

← →
Павел Калугин © (2007-01-31 11:00) [10]

> [3] Sergey13 © (31.01.07 10:01)

← →
Павел Калугин © (2007-01-31 11:01) [11]

> [3] Sergey13 © (31.01.07 10:01)

> МС - это сервер уровня предприятия и выше

с каких пор?

← →
Sergey13 © (2007-01-31 11:10) [12]

> [11] Павел Калугин © (31.01.07 11:01)

А что, нет?

> [9] tesseract © (31.01.07 10:58)
> FB вообще-то нормально себя чуствует и при нагрузке уровня предприятия.
Ну и что? На жигулях то-же можно песок возить, но самосвалом при этом они не становятся.
На мой взгляд, основное, что не хватает ИБ (и ее клонам, хотя за последние их версии не ручаюсь) для использования в серьезных проектах - это отсутствие механизма типа лога транзакций (или архивных логов у Оракла). Т.е. данные введенные после бэкапа ничем не защищены от краха системы.

← →
DrPass © (2007-01-31 11:12) [13]

Ну и возможности языка TransactSQL все-таки повыше будут

← →
Павел Калугин © (2007-01-31 12:12) [14]

> [12] Sergey13 © (31.01.07 11:10)

это имеенно про "жигули и песок"
Хотя если в Вашем понимании предприятие это рабочих мест 20-50 а "выше" это до 60-ти до таки да.
а если пользователей активных от 300 и выше , и много выше это масштаб чего?

← →
Ega23 © (2007-01-31 12:24) [15]

Тут целый ряд отличий, начиная от различных сертификаций заказчиком, цены на продукт, масштабом использования и т.п.
Что понравидось в IB(FB) - можно к sp как к таблице обратиться.
Что не понравилось в IB(FB) - генераторы.
Это из личных наблюдений. Хотя я больше по MSSQL, с IB(FB) так, игрался чуток...

← →
tesseract © (2007-01-31 12:26) [16]

> Что не понравилось в IB(FB) - генераторы.

Потом понравяться, и триггеры тоже ничего :-)

← →
Ega23 © (2007-01-31 12:28) [17]

> Потом понравяться, и триггеры тоже ничего :-)

Скорее всего так и не понравятся. Похоже Oracle начинаем продвигать...

← →
Desdechado © (2007-01-31 12:39) [18]

Ega23 © (31.01.07 12:28) [17]
>> Потом понравяться, и триггеры тоже ничего :-)
> Скорее всего так и не понравятся. Похоже Oracle начинаем продвигать.
В оракле то же механизм, только сиквенсами зовется. Так что придется любить :)
Имхо, гораздо удобнее автоинкрементных полей.

← →
Ega23 © (2007-01-31 12:41) [19]

> Имхо, гораздо удобнее автоинкрементных полей.

Я автоинкрементом крайне редко стараюсь пользоваться. Не у справочных таблиц, в общем. Так, чтобы уникальность была, причём не по составным полям, а то с клиента позиционироваться не удобно.. :)

← →
Johnmen © (2007-01-31 12:48) [20]

> В чём преимущества MSSQL2000 над IB6X(FB1.5.X)?

Главное приемущество - MSSQL2000 платный в отличие от FB1.5.X.
И если не заплатишь, то к тебе ввалится кампания гостей во главе с О.Дергуновой и местным прокурором. Ну а гостям то мы всегда рады!

← →
Ega23 © (2007-01-31 12:51) [21]

> Главное приемущество - MSSQL2000 платный в отличие от FB1.
> 5.X.
> И если не заплатишь, то к тебе ввалится кампания гостей
> во главе с О.Дергуновой и местным прокурором. Ну а гостям
> то мы всегда рады!

Для скупердяев MSDE имееццо :)

← →
Sergey13 © (2007-01-31 12:52) [22]

> [14] Павел Калугин © (31.01.07 12:12)
> Хотя если в Вашем понимании предприятие это рабочих мест
> 20-50 а "выше" это до 60-ти до таки да.
> а если пользователей активных от 300 и выше , и много выше
> это масштаб чего?
В моем понимании - предприятие это как раз таки больше 100 мест.
При подборе оптимального сервера важно не только количество одновременных сессий, но и характер их работы (можно и одной сессией все положить). На очень крупных проектах вроде как больше используются юникс-ориентированные сервера.

← →
pasha_golub © (2007-01-31 12:54) [23]

> Desdechado © (31.01.07 12:39) [18]

> Имхо, гораздо удобнее автоинкрементных полей.
>

В разы удобней, ИМХО.

← →
Johnmen © (2007-01-31 13:01) [24]

> Для скупердяев MSDE имееццо :)

Ну мы же говорим о взрослых версиях, а не о ембеддед :)

← →
Skyle © (2007-01-31 13:07) [25]

> Johnmen © (31.01.07 13:01) [24]
>
> > Для скупердяев MSDE имееццо :)
>
>
> Ну мы же говорим о взрослых версиях, а не о ембеддед :)

Ну Desktop Engine как бы тоже не очень embedded :)
Правда и не сказать, что взрослый.

← →
Ega23 © (2007-01-31 13:13) [26]

> В разы удобней, ИМХО.

Это спорный вопрос.
А, вот ещё что не понравилось: рассылка событий от сервера к клиенту на, например, обновление данных. В принципе, особого криминала в этом нет, да и в MSSQL аналог есть (но такой мутный!). Но это, ИМХО, развращает: народ начинает держать открытые выборки с тысячами записей на клиенте.

← →
pasha_golub © (2007-01-31 14:15) [27]

> Ega23 © (31.01.07 13:13) [26]

> народ начинает держать открытые
> выборки с тысячами записей на клиенте.

За это надо бить "титовым" по затылку.

← →
jack128 © (2007-01-31 14:15) [28]

Sergey13 © (31.01.07 11:10) [12]
> [9] tesseract © (31.01.07 10:58)
> FB вообще-то нормально себя чуствует и при нагрузке уровня предприятия.
Ну и что? На жигулях то-же можно песок возить, но самосвалом при этом они не становятся.
На мой взгляд, основное, что не хватает ИБ (и ее клонам, хотя за последние их версии не ручаюсь) для использования в серьезных проектах - это отсутствие механизма типа лога транзакций (или архивных логов у Оракла).

А что, "поломанный" лог транзакций сильно помогает в востановлении данных?
В FB - если те так важна надежность, делай теневую копию базы, и всех делов. Правда от сгоревшего сервера - ничто не поможет :-)

← →
jack128 © (2007-01-31 14:16) [29]

Ega23 © (31.01.07 13:13) [26]
народ начинает держать открытые выборки с тысячами записей на клиенте.
Хм. А как одно с другим связано??

← →
Ega23 © (2007-01-31 14:20) [30]

> Хм. А как одно с другим связано??
>

Просто в IB(FB) это реализовать гораздо проще. Вот и реализовывают... :)

← →
Skyle © (2007-01-31 14:25) [31]

> Ega23 © (31.01.07 13:13) [26]
> А, вот ещё что не понравилось: рассылка событий от сервера
> к клиенту на, например, обновление данных. В принципе, особого
> криминала в этом нет, да и в MSSQL аналог есть (но такой
> мутный!).

А как это делается кошерно?
То, о чём я думаю (триггер + extended procedure) мне вообще не нравится...

← →
jack128 © (2007-01-31 14:27) [32]

Ega23 © (31.01.07 14:20) [30]
Просто в IB(FB) это реализовать гораздо проще
Ивенты?? Ну так это плюс к IB/FB, а не минус :-)

← →
КиТаЯц © (2007-01-31 14:43) [33]

Неправильная постановка вопроса. ИМХО, не преимуществ.

зы. Не настаиваю. Личное мнение

← →
Sergey13 © (2007-01-31 14:45) [34]

> [28] jack128 © (31.01.07 14:15)
> В FB - если те так важна надежность, делай теневую копию базы, и всех делов.
Это все таки не совсем одно и то-же. Крахи бывают и логические - случайно грохнули не ту таблицу (схему) например. Теневая при этом не спасет, как я понимаю. А логи (это про Оракл, про МС не знаю) можно копировать в разные места в том числе и по сети и поднимать (автоматом или по желанию) на другом сервере. ИМХО значительно гибче и надежнее.

← →
pasha_golub © (2007-01-31 15:16) [35]

> Крахи бывают и логические -

Мой самый любимый забыть добавить WHERE в DELETE или UPDATE запрос. :)

← →
Sergey13 © (2007-01-31 15:21) [36]

> [35] pasha_golub © (31.01.07 15:16)

Это хоть можно откатить... иногда. 8-)
Вот drop уже не откатишь.

← →
Romkin © (2007-01-31 15:22) [37]

на IB/FB менять метаданные в процессе работы - самоубийство :)
А так - вчера только забыл where для update :)))
Но ничего и не случилось, оттестил же предварительно на своей БД.

← →
Павел Калугин © (2007-01-31 15:34) [38]

> [22] Sergey13 © (31.01.07 12:52)

не знаю как 2005 а 2000 не тянет такое, по моим данным.
Естественно если это серьезнее телефонного справочника:)
И если речь не о порядке сотен а о порядке тысяч клиентов то увы..

← →
stone © (2007-01-31 15:41) [39]

> Павел Калугин © (31.01.07 15:34) [38]
> не знаю как 2005 а 2000 не тянет такое, по моим данным.

Не правильные данные у тебя. У нас используется MSSQL 2000, одновременно работает несколько сотен пользователей с базой в несколько десятков гигабайт. Особых проблем с производительностью не замечено.

← →
Ega23 © (2007-01-31 15:42) [40]

> Не правильные данные у тебя. У нас используется MSSQL 2000,
> одновременно работает несколько сотен пользователей с базой
> в несколько десятков гигабайт. Особых проблем с производительностью
> не замечено.
>

Просто у вас индексы правильно расставлены. А Пашки - нет... :)))

← →
Игорь Шевченко © (2007-01-31 15:43) [41]

"И плюнул работодателю на стол"

← →
Ega23 © (2007-01-31 15:47) [42]

> "И плюнул работодателю на стол"

Дык не Oracle чай обсуждаем... :))))))))))))

← →
Anatoly Podgoretsky © (2007-01-31 16:40) [43]

> Kostafey (31.01.2007 10:13:06) [6]

И для КПК

← →
Anatoly Podgoretsky © (2007-01-31 16:41) [44]

> Sergey13 (31.01.2007 10:01:03) [3]

Я бы начал с модели распространения и поддержки, как существенные различия.

← →
Anatoly Podgoretsky © (2007-01-31 16:43) [45]

> tesseract (31.01.2007 10:58:09) [9]

> Из недостатков - относительно труден в настройке баз и прав пользователя.

Не понятно к чему относится, но если к MSSQL то сложностей нет, от чистого ГУИ до полной интеграции в рамках конкретного приложения. И промежуточные уровни.
Про ФБ не в курсе насчет сложностей и интеграции, но не думаю, что плохо.

← →
Anatoly Podgoretsky © (2007-01-31 16:45) [46]

> Павел Калугин (31.01.2007 11:01:11) [11]

С давних, МС сравнение ведет с Оракл на уровне сложных многокластерных систем.
Тесты подтверждают это, но оснавная разница в стоимости вложения, если по предельным характеристиками, то МС дешевле миллионов на 30.
Но вот если этого уровня уже не достаточно, то у Оракла нет конкуренции. На уровне мульти пентабайтных баз на основе железа от ИБМ RS6000 и выше, вот тут у МС нет ничего для этого уровня.

← →
Anatoly Podgoretsky © (2007-01-31 16:48) [47]

> Johnmen (31.01.2007 12:48:20) [20]

Между прочим это не шутка, а именно преимущество, ну и бесплатные версии есть, у меня дома одна постоянно крутится и на предприятии на новом сервере, на каждом компьютере будет стоять, кроме компьютеров для БД, там будут платные MSSQL сервера, два или три.

← →
Anatoly Podgoretsky © (2007-01-31 16:50) [48]

> Johnmen (31.01.2007 13:01:24) [24]

> Ну мы же говорим о взрослых версиях, а не о ембеддед :)

Тогда датацентр

← →
Anatoly Podgoretsky © (2007-01-31 16:51) [49]

> Skyle (31.01.2007 13:07:25) [25]

Смотря что считать за embeded. FB вроде тоже как не embeded, хотя и так позиционируется.

← →
Ega23 © (2007-01-31 16:52) [50]

> FB вроде тоже как не embeded, хотя и так позиционируется.

Нет, там есть и серверное исполнение и embedded вариант

← →
tesseract © (2007-01-31 16:53) [51]

> Anatoly Podgoretsky © (31.01.07 16:40) [43]
> > Kostafey (31.01.2007 10:13:06)
> [6]И для КПК

Опплюесси под КПК. Sqlite лучше выходит по всем статьям.

> FB вроде тоже как не embeded, хотя и так позиционируется.

Есть Embedded версия. Немного подглючитвает на Collation но в целом более чем работоспособна.

← →
sniknik © (2007-01-31 17:06) [52]

>> FB вроде тоже как не embeded, хотя и так позиционируется.
> Нет, там есть и серверное исполнение и embedded вариант
embedded это внедренное(встроенное), ну а разве у FB для приложения это так? нет, там просто весь сервер в dll впихивают, которая в нормальном режиме только посредник (вот для этой dll-ли оно embedded, но не для приложения).
ну вот, в правильном понимании слова оно не встроенное, хотя так и называется, близко к этому но все же не то. (может поэтому другое название того же самого personal? вот тут уж никаких претензий с придирками быть не может)

← →
Павел Калугин © (2007-01-31 17:07) [53]

> [41] Игорь Шевченко © (31.01.07 15:43)

три раза:)

> [39] stone © (31.01.07 15:41)

в моем понимании масштаб предприятия это скажем ERP для концерна типа "Даймлер Крайслер"..

> [46] Anatoly Podgoretsky © (31.01.07 16:45)

А есть еще и DB2 усть еще и Sybase ASE

← →
tesseract © (2007-01-31 17:15) [54]

> Но вот если этого уровня уже не достаточно, то у Оракла
> нет конкуренции. На уровне мульти пентабайтных баз на основе
> железа от ИБМ RS6000 и выше, вот тут у МС нет ничего для
> этого уровня.

MS дешевле обойдёться? В эту сумму как обычно не включают расходы на оборудование. А оно в случаем MS не очень-то дёшево выходит + затраты на Enteprise Server тоже нехилые. Sony вообще на Enterprise DB переходит c Оракла. А оборот у них в 64 гибабакса. Сколько в байтах не знаю.

← →
ANB © (2007-01-31 17:31) [55]

> Вот drop уже не откатишь.

В 10-ке - откатывается на ура. Дропнутая табличка лежит в корзине. Прикольно. Меня раз уже эта фича выручила. :)

> одновременно работает несколько сотен пользователей с базой
> в несколько десятков гигабайт.

Малые базы данных - это БД до 20 террабайт. :)

← →
TohaNik © (2007-01-31 17:39) [56]

> Малые базы данных - это БД до 20 террабайт. :)

Да уж, столько уже не выпить...

← →
Ega23 © (2007-01-31 17:43) [57]

> MS дешевле обойдёться? В эту сумму как обычно не включают
> расходы на оборудование. А оно в случаем MS не очень-то
> дёшево выходит + затраты на Enteprise Server тоже нехилые.

AFAIK, если с доменом покупать - не сильно дорого. Точнее, сильно снижают цену.

> Sony вообще на Enterprise DB переходит c Оракла.

Барнунов на КБД-2006 вообще-то про Postgres говорил. Хотя я тут не в теме.

← →
tesseract © (2007-01-31 17:45) [58]

> Барнунов на КБД-2006 вообще-то про Postgres говорил. Хотя
> я тут не в теме.

Это клон ейный клон, вроде как SQL оракловский эмулирует -
http://www.enterprisedb.com/

← →
Anatoly Podgoretsky © (2007-01-31 19:36) [59]

> Ega23 (31.01.2007 16:52:50) [50]

Ну мы опять возвращаемся к терминологии.
Что по твоему embeded?

← →
Anatoly Podgoretsky © (2007-01-31 19:39) [60]

> sniknik (31.01.2007 17:06:52) [52]

К термину Персонал претензий нет, но тогда исходя из этого можно любой Персонал назвать embeded для весомости, количество dll не играет роли. MS SQL даже более embeded, если он встроен в железо, например в КПК, прибор.

Для меня embeded когда движок встроен в приложение, как например TDbBF/Absolute Database

← →
Anatoly Podgoretsky © (2007-01-31 19:41) [61]

> tesseract (31.01.2007 17:15:54) [54]

Я вообще то не про Enteprise Server, а про DataCenter

← →
Anatoly Podgoretsky © (2007-01-31 19:42) [62]

> ANB (31.01.2007 17:31:55) [55]

> Малые базы данных - это БД до 20 террабайт. :)

Устаревшие сведенья.

← →
Джо © (2007-01-31 19:47) [63]

А Постгрес забыли попинать?! :)

← →
Ученик чародея © (2007-01-31 19:58) [64]

> Sergey13 © (31.01.07 11:10) [12]
>
> > [11] Павел Калугин © (31.01.07 11:01)
>
> А что, нет?
>
> > [9] tesseract © (31.01.07 10:58)
> > FB вообще-то нормально себя чуствует и при нагрузке уровня
> предприятия.
> Ну и что? На жигулях то-же можно песок возить, но самосвалом
> при этом они не становятся.
> На мой взгляд, основное, что не хватает ИБ (и ее клонам,
> хотя за последние их версии не ручаюсь) для использования
> в серьезных проектах - это отсутствие механизма типа лога
> транзакций (или архивных логов у Оракла). Т.е. данные введенные
> после бэкапа ничем не защищены от краха системы.

Shadow копия? Хотя от кривых рук(редактирование метаданных при активных коннектах) таки да незащищены.

← →
Anatoly Podgoretsky © (2007-01-31 20:10) [65]

> Ученик чародея (31.01.2007 19:58:04) [64]

Shadow это не совсем то, с помощью логов транзакций, возможно восстаноление с точностью до секунды. Например случайно удалил кучу записей, то тут же можно восстановиться в точку перед удалением. Кроме того эти логи резко повышают быстродействие.

← →
tesseract © (2007-01-31 21:23) [66]

> Кроме того эти логи резко повышают быстродействие.

Логи ? повышают? С каких пор дополнительная функциональность начала повышать быстродействие? Кэширование конечно лучше у оракла.

← →
Anatoly Podgoretsky © (2007-01-31 21:41) [67]

> tesseract (31.01.2007 21:23:06) [66]

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

← →
tesseract © (2007-01-31 21:45) [68]

> Все элегантно и дополнительный бонус восстановление до любой
> точки, с точностью до секунды.

Не знаю денег столько не давали. Я в основном по выражению Абрамова по "нарушению целостности данных". В моём опыте база без триггеров и версий в чистую сливает блокировкам и автоинкременту. Слоник - становиться заменой mssql в 1с. Вот для меня это важно, ибо то, с чем придёться работать.

← →
Anatoly Podgoretsky © (2007-01-31 21:49) [69]

> tesseract (31.01.2007 21:45:08) [68]

Ни фига не понял, что ты сказал, да ладно не важно.
Вижу что понял принцип работы и почему ускоряет без потери целостности.
Разумеется это работает по полной, только тогда когда достаточно памяти, когда вся база помещается в память, но даже когда не помещается, ускорение все равно есть, но уже не такое.

← →
tesseract © (2007-01-31 21:52) [70]

> Разумеется это работает по полной, только тогда когда достаточно
> памяти, когда вся база помещается в память, но даже когда
> не помещается, ускорение все равно есть, но уже не такое.

В практике работы с 1с встерчался с такой фичой MsSQl как "фиксация таблиц в памяти" - может это имееться в виду?

ЗЫ: Я про криворукость персонала, оно случаеться в 10^3 раз чаще, чем сбои аппаратуры.

← →
Anatoly Podgoretsky © (2007-01-31 21:58) [71]

> tesseract (31.01.2007 21:52:10) [70]

Вообще то это какое то особое свойство 1С, я же про штатное средство MS SQL
Принцип простой, изменения данных в таблицах базы делаются в памяти без записи на диск. Изменения логов всегда с обязательной записью на диск.

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

← →
tesseract © (2007-01-31 22:03) [72]

> Вообще то это какое то особое свойство 1С, я же про штатное
> средство MS SQL

Это штатное MS SQL. Просто 1с-ники знают приколы MS SQL получше многих. Кстати сразу въезжаешь в отличие "плоских" DBF от "страничных" современных баз. Что-то быстрее, что-то медленнее.

А про кэширование записи + откат до точки мне Паша Калугин ещё в 2002 дифирамбы пел. Когда MS SQL от SyBase отличался только интеграцией с AD.

← →
Anatoly Podgoretsky © (2007-01-31 22:07) [73]

> tesseract (31.01.2007 22:03:12) [72]

Это хорошая возможность, но это костыль для неаккуратных, реально такого никогда быть не должно, проще сменить главбуха и правильнее.

← →
tesseract © (2007-01-31 22:10) [74]

> проще сменить главбуха и правильнее.

А он-то тут причём ? Бухгалтерия вжикает и на файл-сервере. Это на торговой базе всё тормозит, поработаешь с ней вплотную, сдача квартальной отчетности праздником будет.

← →
sniknik © (2007-01-31 23:34) [75]

тока прочитал, анекдот... похоже в тему ;о)))
=========================================
Новая игра от Мiсrоsоft: SQL 2005. Основная задача: уничтожить базу противника.

без комментариев. :)

← →
Anatoly Podgoretsky © (2007-02-01 20:16) [76]

> sniknik (31.01.2007 23:34:15) [75]

Никогда не слышал про игру Memory War

← →
Аноним (2007-02-01 20:55) [77]

Не знаю, как там на уровне предприятия, а вот на уровне рабочей группы у меня используются оба. И MSSQL будет использоваться ровно до тех пор, пока не дойдут руки перевести все хозяйство на FB
И, судя по всему, дойдут они уж скоро

← →
Sergey13 © (2007-02-02 08:21) [78]

> [77] Аноним (01.02.07 20:55)

Это ты типа пальчиком погрозил?

← →
MsGuns © (2007-02-02 09:26) [79]

Минусы "Скалы":
На стороне сервера -
1. Тяжел (относительно) в установке
2. Тормозит комп, поэтому надо устанавливать на выделенном сервере
3. Громоздок в администрировании.
4. Каждая БД требует регистрации. Нельзя перенести БД просто как файл - надо бакапить с последующим рестором
5. Пахабно реализован механизм временных таблиц и курсоров
6. Невозможна передача клиенту данных по мере их получения (типа Suspend) - надо все собрать в кучу (таблица,курсор) и только потом передать

На стороне клиента -
1. Мутное (относительно) управление транзакциями
2. Нет генераторов, а автоинкременты требуют особого знания технологии работы с ними
3. Куцые триггеры
4. Нельзя получить данные из хранимки простым Select from <StoredProc> - nприходится писать функции или представления
5. Совершенно инвалидный клиентский инструментарий (EM+QA) - особенно на фоне IBExpert

Но, конечно, есть и плюсы ;))

← →
Sergey13 © (2007-02-02 09:32) [80]

> [79] MsGuns © (02.02.07 09:26)
> 5. Совершенно инвалидный клиентский инструментарий (EM+QA)- особенно на фоне IBExpert
Это ты с родными оракловыми наверное не работал. 8-)

> 5. Пахабно реализован механизм временных таблиц и курсоров

А что похабного в механизме временных таблиц?

> 1. Мутное (относительно) управление транзакциями

А что в нем мутного?

> 3. Куцые триггеры
>

Эт почему это? Или это намек на отсутствие Before-триггеров?

> 5. Совершенно инвалидный клиентский инструментарий (EM+QA)
> - особенно на фоне IBExpert
>

Не в порядке возражения, а для удовлетворения любопытства: что можно в IB Expert, чего нельзя (или страшно неудобно) делать в EM+QA?

FireBird - рулезфарева!

Плюсы:

+ Очень хорошие темпы развития, хоть и опенсорс!
http://www.firebirdsql.org/index.php?op=devel&sub=engine&id=roadmap_2007&nosb=1

+ По соотношению условия_лицензирования/производительность - рвет всех!
http://interbase.blogspot.com/2006/07/mysql.html

+ клиентский инструментарий к другим СУБД не дешев - особенно на фоне IBExpert, FIB+.

Минусы:

- По совокупности всех возможностей не дотягивает и не будет никогда дотягивать до пропиетарных СУБД (т.к. опенсорс).

Там никогда не будет Server Pages, Internal Java, Object Tables... и т.д. и т.п., но так ли это надо?

> + По соотношению условия_лицензирования/производительность
> - рвет всех!

Sqlite рвёт всех :-) Но он не сервер.

Хм... А что там в IB с репликацией?

> Там никогда не будет Server Pages, Internal Java, Object Tables...
А на фиг все это ?
Для реализации www есть InterClient, лично сам пользую PHP, одни знакомые тоже самое на Python развели. При этом всем обеспечивается полная кроссплатформенность, у меня на работе NT-домен, у заказчиков - 80% Fedora LINUX. Перенос осуществляется путем копирования папки.

А на счет "корпоративности" MSSQL или Oracle, у меня лично есть пример базы данных машиностроительного завода, которая крутиться на FB 1.5 classic. Около 500 постоянно поключенных и около 1200 пик пользователей (в конце квартала) и ниче, справляется. При это все чертежи AutoCAD-овские в БЛОБах хранятся, для централизованности. Объем базы 15 ГБ.

> что можно в IB Expert, чего нельзя (или страшно неудобно) делать в EM+QA?

Контроль версий исходников хранимых процедур, например. Или сравнение двух баз данных и автоматическиое получение скрипта "разности" баз данных. Очень удобно, когда банда разработчиков чел. 10 над одной базой трудится.
Я не говорю уже про автоподсказчик кода, а-ля Делфи.

to PEAKTOP © (02.02.07 10:54) [86]:
>сравнение двух баз данных и автоматическиое получение скрипта
>"разности" баз данных.
Adept SQL Diff. Не от MS, правда. Ну так и IBExpert не от производителей IB...

>Я не говорю уже про автоподсказчик кода, а-ля Делфи.
EMS SQL Manager. Близкий родственник IB Expert.

> ZeroDivide © (02.02.07 10:15) [82]
> Там никогда не будет Server Pages, Internal Java, Object
> Tables... и т.д. и т.п., но так ли это надо?

В тройке обещают яву прикрутить. Да, в принципе, уже в некоторых ветках
сдалано. (Yaffil?)

> MsGuns © (02.02.07 09:26) [79]
> 4. Каждая БД требует регистрации. Нельзя перенести БД просто
> как файл - надо бакапить с последующим рестором

Паааазвольте, а как же attach/detach?
Всю жизнь им пользуюсь, а оказывается нету такого :(

> + По соотношению условия_лицензирования/производительность - рвет всех!
а по соотношению цена/качество халявное пиво вне конкуренции!!! :)

← →
Weter (2007-02-02 13:02) [91]

>Weter (02.02.07 13:02) [91]
>Ну сие вообще похоже на детский лепет.

Урра ! Взрослый пришел - сейчас что-нибудь умное скажет, ага ?

Всяк кулик свое болото хвалит, как говорицца.
Интересно, а почему в сабже сравниваюцца 2000 и 1.5, а не 2005 и 2.0?

[79] MsGuns c (02.02.07 09:26)

> 1. Тяжел (относительно) в установке

Хм... во народ ленивый пошел! Запустить инсталлер и жать все время на кнопарь "Далее" тяжело ему! :)
Да, афигенный минус, да ищщо и со стороны сервера. :)

> 2. Тормозит комп, поэтому надо устанавливать на выделенном
> сервере

Ну это смотря чего на нем делать, на сервере этом. Неужели это минус, когда сервер БД умеет сожрать 100% ресурсов для наискорейшего выполнения поставленной перед ним задачи?

> 3. Громоздок в администрировании.

Вах! Какая именно из задач администрирования там громоздкая?

> 4. Каждая БД требует регистрации. Нельзя перенести БД просто
> как файл - надо бакапить с последующим рестором

Ты просто не пробовал еще. :)
На самом деле можно и без бакапа. :)

> 5. Пахабно реализован механизм временных таблиц и курсоров

Работать можно.

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

Не люблю серверные курсоры. Люблю клиентские. Люблю что все и сразу было у клиента. :)
Естественно, все, что ему нужно, а не все содержимое стотысячестрочной таблицы или въюхи. :)

> 1. Мутное (относительно) управление транзакциями

Работать можно. :))

> 2. Нет генераторов, а автоинкременты требуют особого знания
> технологии работы с ними

На счет генераторов - согласен, а на счет особого умения работы с автоинкрементом??!!

> 3. Куцые триггеры

Согласен.

> 4. Нельзя получить данные из хранимки простым Select from
> <StoredProc> - nприходится писать функции или представления

Выход, таки, есть и не один? :)

> 5. Совершенно инвалидный клиентский инструментарий (EM+QA)
> - особенно на фоне IBExpert

IBExpert, очевидно, входит в дистрибутив фаерберда? :)
А если нет, то может правильнее сравнивать IBExpert со сторонним клиентским инструментарием? :)

> А если нет, то может правильнее сравнивать IBExpert со сторонним
> клиентским инструментарием? :)

По стоимости?

> > 2. Нет генераторов, а автоинкременты требуют особого знания
>
> > технологии работы с ними

А расскажите что же в них этакого ?
Я что-то совсем не понял как они работают.
Берется таблица в ней id - автоинкремент.
Копирую таблицу. Изменяю ID одной из записей. Делаю insert * from
копии таблицы. По идее-то в измененную таблицу должна добавиться запись,
id которй не совпадает ни с одной из существующих. Но этого не происходит.
Не знеате почему ?
Если просто удалить одну из записей и после этого опять сделать insert * from
копии таблицы, то запись будет восстановлена...
такое ощущение, что СУБД смотрит не на id ?

> tesseract (03.02.2007 19:46:34) [94]

Ну например EMS бесплатно, лучше может быть только когда автор будет платить пользователям.

> Kostafey (03.02.2007 19:49:35) [95]

Не знеате почему ?

Знаем, у тебя ошибка в программе.

> [97] Anatoly Podgoretsky © (03.02.07 20:04)

Знаем, у тебя ошибка в программе.

Нет-нет. Экспериментировал я в самом SQL Server Management Studio. Писал запросы.
ПРОграмма не при чем.

Просто сосздается впечатление, что кроме уникальности id проверяются еще что-то ?

> Kostafey (03.02.2007 20:14:38) [98]

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

> ... Писал запросы.
> ПРОграмма не при чем.
понятно не причем, была бы при чем если бы писал программу, а так ошибка в том что писал, в запросах...
либо написал не так, либо ожидал не то, что писал.

но какая разница?

[94] tesseract © (03.02.07 19:46)

> По стоимости?

Вах, савсэм умный, да? :)
Ну тогда сравни инструментарий который есть в комплекте с фаербердом, с бесплатной экспресс студией от микрософта.
:)

Из плюсов mssql - отличная документация от разработчика, да еще и на русском.
В отличие от фаера, где нормальный комплект днем с огнем не сыщешь, есть только по старью IB6х, или какие-то подборки по кусочкам, то там, то тут.
Кистати, вот и не знаю до сих пор - можно ли в нем делать не ХП, а функции, вызываемые из запросов и возвращаемые одно значение, или (о-ужас!) функции можно делать только utf, а на унутреннем языке низзя? :)

И исчо вопрос.
Неужели правда, что для фаера оптимизатор писали враги нерода? Без плана написаного ручками почти на всех запросах, за исключением простейших, план подбирается далекий от оптимального. :(
Или у меня руки кривые? :)

> [99] Anatoly Podgoretsky © (03.02.07 21:06)

> [100] sniknik © (03.02.07 21:24)

> наверно колдовал,
Нет, ну определенно мистика ! Сделал то же самое - все получилось !

> При том в отличии от тебя нет оснований сомневаться в их
> квалификации.

Не устану напоминать, что в моей квалификации также не следует сомневаться: она оставляет желать лучшего, :)
в отличие от стремления к обучению - последнего хоть отбавляй !

to Danilka © (03.02.07 22:08) [101]:
>или (о-ужас!) функции можно делать только utf, а на унутреннем языке
>низзя?
Хде? В IB? В IB низзя.

>Неужели правда, что для фаера оптимизатор писали враги нерода?
Ну там, насколькоя понимаю, с любимым "козырем" IB - select from procedure вообще отдельная история с планами...

Кстати, в MS SQL тоже иной раз такие выкрутасы попадаются с планами... Ну, напимер при вызове процедуры из QA получаем один план, а из своего приложения - совсем другой... :o)

>Danilka © (03.02.07 18:09) [93]
>Хм... во народ ленивый пошел! Запустить инсталлер и жать все время на кнопарь "Далее" тяжело ему! :)

Ну не так все просто. В частости, есть нюансы при установке на некоторые версии винды.

>Ну это смотря чего на нем делать, на сервере этом. Неужели это минус, когда сервер БД умеет сожрать 100% ресурсов для наискорейшего выполнения поставленной перед ним задачи?

Умение забивать проц под завязку вообще "фишка" мелкософта. А MS SQL это касается в первую очередь. Попробуйте на собственном компе установить сервер, с другого запустить какую-нибудь "долгоиграющую" хранимку на нем, и потом работайте в свое "удовольствие" ;)

> 3. Громоздок в администрировании.
>Вах! Какая именно из задач администрирования там громоздкая?

Первая, которая приходит в голову - эти жуткие логи, которые надо периодически чистить, дабы не сдохла "рабочая" процедура каскадного обновления (удаления),- иначе винт мгновенно забивается мусором. Да и тормозят эти логи сервер не по-детски.

Второе - невозможность хранения непосредственно в БД скриптов, а также "нештатной" информации (типа аннотаций к БД, пояснений к схемам и т.д.)

>Ты просто не пробовал еще. :)
>На самом деле можно и без бакапа. :)

Возможно. Я себя "аксакалом" в "скале" на считаю - более того, в моей группе есть ребята, соображающие в нем получше. За любой совет и рекомендции всегда и всякому благодарен.

>> 5. Пахабно реализован механизм временных таблиц и курсоров
>Работать можно.

Пахать можно и на козе. Вот удобно ли ?

>Не люблю серверные курсоры. Люблю клиентские. Люблю что все и сразу было у клиента. :)

Позвольте все же МНЕ решать что мне удобно в каждом конкретном случае,- в ИБ можно и так, и эдак.

>> 1. Мутное (относительно) управление транзакциями
>Работать можно. :))

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

>На счет генераторов - согласен, а на счет особого умения работы с автоинкрементом??!!

Блин, сколько уж говорено..
Для того, чтобы определить гарантированный ИД записи в ИБ (и не только)не нужно делать вставку в таблицу. Понимаешь - НЕ НУЖНО ! Только не говори, что знать ИД до вставки не нужно ТЕБЕ, лады ? ;)

>> 4. Нельзя получить данные из хранимки простым Select from
>> <StoredProc> - nприходится писать функции или представления
>Выход, таки, есть и не один? :)

Выход, как известно, есть всегда, только вот КУДА

>IBExpert, очевидно, входит в дистрибутив фаерберда? :)
>А если нет, то может правильнее сравнивать IBExpert со сторонним клиентским инструментарием? :)

Ну с этим, конечно, не поспоришь. Но я все никак не могу привыкнуть к этой "горькой парочке". Иногда складывается впечатление, что этот инструмент писАлся с тем, чтобы как можно меньше народу им пользовался.

to MsGuns © (03.02.07 23:45) [104]:
>Первая, которая приходит в голову - эти жуткие логи, которые надо
>периодически чистить
Хорошя крыша, она, как известно, летает сама. Вот и логи тоже. Сами чистятся. :)

>Второе - невозможность хранения непосредственно в БД скриптов
В смысле? Скрипт чем-то сильно от ХП отличается?

> а также "нештатной" информации (типа аннотаций к БД, пояснений к
>схемам и т.д.)
Мда... А мужики-то не знают...

>Пахабно реализован механизм временных таблиц и курсоров
В чем пахабность-то, не поясните? Кстати, помимо временных таблиц есть еще такая штука, как таблицы-переменные. Гораздо удобнее временных таблиц.

>что-то подобное соорудить в "Скале", мягко говоря, неудобно
Поконкретнее можно? А то я что-то не понимаю, какие проблемы с транзакциями... Ну begin tran... Ну commit... Ну Rollback... Чего невнятного-то?

> MsGuns (03.02.2007 23:45:44) [104]

Страсти какие рассказываешь и главно ни одна из них не относится к MSSQL2000

[103] vuk © (03.02.07 23:24)
> Ну, напимер при вызове процедуры из QA получаем один план,
> а из своего приложения - совсем другой... :o)

Встречался с чем-то подобным, там, вроде, немного не так.
Кода пишешь скрипт в QA, задаешь переменные, присваиваешь им значения и в момент выполнения данный скрипт парсится сервером, строится план и выполняется.
Когда-же мы потом оформляем скрипт ввиде ХП, скрипт парсится и строится план для него на этапе создания ХП, причем строится учитывая то, что параметры неизвестны и могут быть любыми.
Из-за этого и получается разный план.

А когда ты выполняешь одно и то-же из клиентского приложения и из QA, то оно и будет одинакого выполняцца, ибо QA для MSSQL такое-же самое обычное клиентское приложение.

to Danilka © (04.02.07 09:56) [107]:
>А когда ты выполняешь одно и то-же из клиентского приложения и из QA,
>то оно и будет одинакого выполняцца
Вот в том-то и дело, что выполнялось по-разному. И был именно вызов ХП, а не скрипт. Грешили на разные настройки соединения, но отличий, кажется, так и не нашли. Тем не менее факт остается фактом. Планы бали разные. И по закону подлости из приложения был жутко неоптимальный.

> vuk (04.02.2007 10:07:48) [108]

И при поочередном выполнение несколько раз?

> vuk (04.02.2007 10:07:48) [108]

А параметры в приложение были?

to Anatoly Podgoretsky:
>И при поочередном выполнение несколько раз?
Угу. И параметры при вызове процедуры одни и те же были. Вызов повторялся несколько раз, что из QA, что из приложения. Ситуация была абсолютно повторяющаяся - тормоза из приложения и нормальная работа из QA. Разница в планах была только в том, что менялся порядок соединения таблиц. В результате вылечили только при помощи хинта force order (соединения таблиц происходят в порядке появления таблиц в предложении from) в запросе.

> vuk (04.02.2007 15:30:51) [111]

Как ты использовал параметры в QA
Я там не нашел такой возможности.

to Anatoly Podgoretsky © (04.02.07 16:07) [112]:
>Я там не нашел такой возможности.
exec dbo.procname param1, param2, ...

Для трудолюбивых можно даже мышей :). Правой кнопкой по названию процедуры в Object Browser и выбираем "Open". Затем перебираем параметры процедуры в списке "Parameters" и задаем их значения в поле "Value". И жмем Execute

В чём преимущества MSSQL2000 над IB6X(FB1.5.X)? Найти похожие ветки