IB vs FB
Модераторы: kdv, Alexey Kovyazin
-
- Сообщения: 1
- Зарегистрирован: 27 окт 2004, 05:11
IB vs FB
Суть вопроса следующая:
существует база на IB 7. Имеет ли смысл поменять сервер на FB?
И в чем плюсы или минусы?
существует база на IB 7. Имеет ли смысл поменять сервер на FB?
И в чем плюсы или минусы?
-
- Сообщения: 22
- Зарегистрирован: 01 ноя 2004, 11:11
Re: IB vs FB
Добрый день!
если все работает и если сервер покрывает потребности предприятия, то смысла нет.Magic&Wizard писал(а):Суть вопроса следующая:
существует база на IB 7. Имеет ли смысл поменять сервер на FB?
И в чем плюсы или минусы?
-
- Сообщения: 12
- Зарегистрирован: 26 окт 2004, 15:47
Ты понимаешь рабоатет то рабоает. Но вопрос как работает. При переходе на 7.1 пришлось подстраиваться под столько глюков. Но каждый раз подстраиваться под них не хочется.
Во вторых первый вопрос был задан про плюсы и минусы.
Я понимаю что лучшее фраг хорошего, но если при переходе на другой SQL сервер делается мало затрат, и при этом выигрывает производительность это никогда не лишнее. Конешно это не относится к простым задачам(когда мало таблиц и мало в них записей и работаю с сервером один пользователь).
С точке зрения проектирования всегда надо орентироваться на мастабируемость системы и т. д. (Задача может усложняться). И если сейчас ее невозможо выполнять за определное время, о при переходе на другой SQL сервер возможно увеличить функцинальность и увеличить число работающих пользователей одновременно.
По моему такой ответ как раз и дан от малого опыта проектирования, так как человек не задумывается о возможностях эволюции продукта и увеличении потребностей.
Во вторых первый вопрос был задан про плюсы и минусы.
Я понимаю что лучшее фраг хорошего, но если при переходе на другой SQL сервер делается мало затрат, и при этом выигрывает производительность это никогда не лишнее. Конешно это не относится к простым задачам(когда мало таблиц и мало в них записей и работаю с сервером один пользователь).
С точке зрения проектирования всегда надо орентироваться на мастабируемость системы и т. д. (Задача может усложняться). И если сейчас ее невозможо выполнять за определное время, о при переходе на другой SQL сервер возможно увеличить функцинальность и увеличить число работающих пользователей одновременно.
По моему такой ответ как раз и дан от малого опыта проектирования, так как человек не задумывается о возможностях эволюции продукта и увеличении потребностей.
при переходе с чего и под какие глюки?Anonymous писал(а):Ты понимаешь рабоатет то рабоает. Но вопрос как работает. При переходе на 7.1 пришлось подстраиваться под столько глюков. Но каждый раз подстраиваться под них не хочется.
плюсов и минусов полно и у того и у другого. у IB7.1 есть временные сист. таблицы (и в 7.5 еще и временные) - у FB их нет. У FB 1.5 есть case, в 7.1 - нет (есть в 7.5). И так далее.Во вторых первый вопрос был задан про плюсы и минусы.
если ты привязан к конкретной функциональности определенной версии сервера, то увы, куда тебе переходить? С IB/FB реален только переход на Оракл, между прочим.Я понимаю что лучшее фраг хорошего, но если при переходе на другой SQL сервер делается мало затрат, и при этом выигрывает производительность это никогда не лишнее.
последний раз такие задачи я видел лет 5 назад.Конешно это не относится к простым задачам(когда мало таблиц и мало в них записей и работаю с сервером один пользователь).
опять же - увеличить что? 400 пользователей на IB/FB это мало? под 30 гиг базы - это мало?сейчас ее невозможо выполнять за определное время, о при переходе на другой SQL сервер возможно увеличить функцинальность и увеличить число работающих пользователей одновременно.
только не надо, пожалуйста. а то этот бумеранг к самому вернется. Масштабируемость путем перехода с одного сервера на другой - это не совсем масштабируемость. Если лень оптимизировать свое ПО и базу, либо улучшать железку для сервера и клиентов - тоже все понятно.По моему такой ответ как раз и дан от малого опыта проектирования, так как человек не задумывается о возможностях эволюции продукта и увеличении потребностей.
А делать прыжки с одного сервера на другой (однотипный) при промышленной эксплуатации - это из ряда вон. Работающие проекты обычно никто не трогает. Новые делают исходя из требуемой функциональности. И все...
На счет:
Точно не уверен, но вроде у FB нет поддержки SMP.
Да насчет новых системных таблиц удобно (но раньше без них обходились).
Оптимизировать запросы тоже не всегда получается.
Если они формируется динамически от пользвателя - фиг ты тут напишешь план.
Я сейчас использую 7.1 sp2 и был бы рад если бы из него убрали все глюки, которые добавили после IB6 и увеличили произвоельность за счет улучшение планирования.
Не фига себе однотипные. У IB 7.x нет класик архитектуры.А делать прыжки с одного сервера на другой (однотипный) при промышленной эксплуатации - это из ряда вон.
Точно не уверен, но вроде у FB нет поддержки SMP.
Да насчет новых системных таблиц удобно (но раньше без них обходились).
Железяками не всегда получится (вспомнтите до IB7 сколько процессоров не ставь, всеравно будет работать на одном) и они стоят денег.Если лень оптимизировать свое ПО и базу, либо улучшать железку для сервера и клиентов - тоже все понятно.
Оптимизировать запросы тоже не всегда получается.
Если они формируется динамически от пользвателя - фиг ты тут напишешь план.
Я сейчас использую 7.1 sp2 и был бы рад если бы из него убрали все глюки, которые добавили после IB6 и увеличили произвоельность за счет улучшение планирования.
под однотипными я имел в виду общую функциональность. разница, конечно, есть, но опять же, переходить с классика FB на IB 7.1 или наоборот - это надо иметь перед глазами четкие тесты по производительности своей системы.
стандартная ситуация. встречный вопрос - ты хоть об одном глюке куда-нибудь сообщил? мне, в форум Борланда, или на qualitycentral.borland.com? если нет, тогда извините, какие-такие глюки...Я сейчас использую 7.1 sp2 и был бы рад если бы из него убрали все глюки, которые добавили после IB6 и увеличили произвоельность за счет улучшение планирования
Один сюда добавил про 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 может затянуться на
необозримое время?
ерунда какая. у Оракла версионность - не совсем версионность. по крайней мере в нем как раз длинный snapshot может в конце-концов обломиться из-за потери версий (по переполнению лога).Сочувствующий писал(а): Вы имеете в виду версионность и "творения" такого типа, в которых начало редактирование накладной знаменуется оператором
BEGIN TRANSACTION, для которого COMMIT может затянуться на
необозримое время?
насчет "творений" - в IB/FB есть транзакции read read_committed которые могут длиться сутками. и кроме того, версионность IB/FB расчитана на работу с длинными транзакциями.
А по сути вопроса - с IB/FB легче переходить на Оракл, потому что
а) версионность или отсутствие блокировок ближе всего
б) синтаксис запросов наименее непохож
в) логика процедур и триггеров примерно совпадает
с остальными серверами данные различия хуже, а следовательно перенос баз с IB/FB на эти сервера - менее реален.
Ну и конечно, отсутствие блокировок по чтению тоже влияет на такой переход. Но заметьте именно отсутствие блокировок по чтению, а не возможность "пускать длинные транзакции".
обещали, это известно уже как минимум 4 месяца.
http://www.rsdn.ru/article/db/yukonnew.xml
версионность будет практически на 90% аналогичная IB/FB.
http://www.rsdn.ru/article/db/yukonnew.xml
версионность будет практически на 90% аналогичная IB/FB.