iBase.ru Forum

Суть вопроса следующая:
существует база на IB 7. Имеет ли смысл поменять сервер на FB?
И в чем плюсы или минусы?

Добрый день!

Magic&Wizard писал(а):Суть вопроса следующая:
существует база на IB 7. Имеет ли смысл поменять сервер на FB?
И в чем плюсы или минусы?

если все работает и если сервер покрывает потребности предприятия, то смысла нет.

Не понял на счет потребностей. У FB значительно больше функциональность или он производительней?

Что не понятного! Работает? Все устраивает? НУ И НЕ ТРОГАЙ, ТО ЧТО УЖЕ РАБОТАЕТ!!! Это правило видимо с опытом усваивается ))

Ты понимаешь рабоатет то рабоает. Но вопрос как работает. При переходе на 7.1 пришлось подстраиваться под столько глюков. Но каждый раз подстраиваться под них не хочется.
Во вторых первый вопрос был задан про плюсы и минусы.
Я понимаю что лучшее фраг хорошего, но если при переходе на другой SQL сервер делается мало затрат, и при этом выигрывает производительность это никогда не лишнее. Конешно это не относится к простым задачам(когда мало таблиц и мало в них записей и работаю с сервером один пользователь).
С точке зрения проектирования всегда надо орентироваться на мастабируемость системы и т. д. (Задача может усложняться). И если сейчас ее невозможо выполнять за определное время, о при переходе на другой SQL сервер возможно увеличить функцинальность и увеличить число работающих пользователей одновременно.
По моему такой ответ как раз и дан от малого опыта проектирования, так как человек не задумывается о возможностях эволюции продукта и увеличении потребностей.

Anonymous писал(а):Ты понимаешь рабоатет то рабоает. Но вопрос как работает. При переходе на 7.1 пришлось подстраиваться под столько глюков. Но каждый раз подстраиваться под них не хочется.

при переходе с чего и под какие глюки?

Во вторых первый вопрос был задан про плюсы и минусы.

плюсов и минусов полно и у того и у другого. у IB7.1 есть временные сист. таблицы (и в 7.5 еще и временные) - у FB их нет. У FB 1.5 есть case, в 7.1 - нет (есть в 7.5). И так далее.

Я понимаю что лучшее фраг хорошего, но если при переходе на другой SQL сервер делается мало затрат, и при этом выигрывает производительность это никогда не лишнее.

если ты привязан к конкретной функциональности определенной версии сервера, то увы, куда тебе переходить? С IB/FB реален только переход на Оракл, между прочим.

Конешно это не относится к простым задачам(когда мало таблиц и мало в них записей и работаю с сервером один пользователь).

последний раз такие задачи я видел лет 5 назад.

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

опять же - увеличить что? 400 пользователей на IB/FB это мало? под 30 гиг базы - это мало?

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

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

А делать прыжки с одного сервера на другой (однотипный) при промышленной эксплуатации - это из ряда вон. Работающие проекты обычно никто не трогает. Новые делают исходя из требуемой функциональности. И все...

На счет:

А делать прыжки с одного сервера на другой (однотипный) при промышленной эксплуатации - это из ряда вон.

Не фига себе однотипные. У IB 7.x нет класик архитектуры.
Точно не уверен, но вроде у FB нет поддержки SMP.

Да насчет новых системных таблиц удобно (но раньше без них обходились).

Если лень оптимизировать свое ПО и базу, либо улучшать железку для сервера и клиентов - тоже все понятно.

Железяками не всегда получится (вспомнтите до IB7 сколько процессоров не ставь, всеравно будет работать на одном) и они стоят денег.
Оптимизировать запросы тоже не всегда получается.
Если они формируется динамически от пользвателя - фиг ты тут напишешь план.
Я сейчас использую 7.1 sp2 и был бы рад если бы из него убрали все глюки, которые добавили после IB6 и увеличили произвоельность за счет улучшение планирования.

под однотипными я имел в виду общую функциональность. разница, конечно, есть, но опять же, переходить с классика FB на IB 7.1 или наоборот - это надо иметь перед глазами четкие тесты по производительности своей системы.

Я сейчас использую 7.1 sp2 и был бы рад если бы из него убрали все глюки, которые добавили после IB6 и увеличили произвоельность за счет улучшение планирования

стандартная ситуация. встречный вопрос - ты хоть об одном глюке куда-нибудь сообщил? мне, в форум Борланда, или на qualitycentral.borland.com? если нет, тогда извините, какие-такие глюки...

Один сюда добавил про udf c блобами. Другие посылал Dmitry Kuzmenko <support@ibase.ru>.

kdv писал(а):встречный вопрос - ты хоть об одном глюке куда-нибудь сообщил? мне, в форум Борланда, или на qualitycentral.borland.com? если нет, тогда извините, какие-такие глюки...

А где можно посмотреть существующие баги?
Я здесь с dimitr-ом общался на тему моих грабель, куда то надо еще сообщать?

Лысый писал(а):А где можно посмотреть существующие баги?

http://sourceforge.net/tracker/?group_i ... tid=109028
или
http://qualitycentral.borland.com

Лысый писал(а):Я здесь с dimitr-ом общался на тему моих грабель, куда то надо еще сообщать?

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

kdv писал(а):
С IB/FB реален только переход на Оракл, между прочим.

А можно с этого места поподробнее?
Вы имеете в виду версионность и "творения" такого типа, в которых начало редактирование накладной знаменуется оператором
BEGIN TRANSACTION, для которого COMMIT может затянуться на
необозримое время?

Сочувствующий писал(а): Вы имеете в виду версионность и "творения" такого типа, в которых начало редактирование накладной знаменуется оператором
BEGIN TRANSACTION, для которого COMMIT может затянуться на
необозримое время?

ерунда какая. у Оракла версионность - не совсем версионность. по крайней мере в нем как раз длинный snapshot может в конце-концов обломиться из-за потери версий (по переполнению лога).

насчет "творений" - в IB/FB есть транзакции read read_committed которые могут длиться сутками. и кроме того, версионность IB/FB расчитана на работу с длинными транзакциями.

А по сути вопроса - с IB/FB легче переходить на Оракл, потому что
а) версионность или отсутствие блокировок ближе всего
б) синтаксис запросов наименее непохож
в) логика процедур и триггеров примерно совпадает

с остальными серверами данные различия хуже, а следовательно перенос баз с IB/FB на эти сервера - менее реален.

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

Вроде в MS SQL 2005 обещают сделать версионость и вроде уже доступны демо версия. Хотя я не совсем в курсе.

обещали, это известно уже как минимум 4 месяца.
http://www.rsdn.ru/article/db/yukonnew.xml

версионность будет практически на 90% аналогичная IB/FB.

Механизм похож, но использование заметно другое. Одно сочетание версионного скана с блокировочным апдейтом чего стоит