LINUX.ORG.RU

Зачем нужна Firebird?

 , ,


0

2

Иногда вижу что используют сабжевую СУБД. Какие у нее преимущества? Почему не используют MySQL (MariaDB) или SQLite? Что это за фрукт такой?

★★★★

Последнее исправление: Black_Roland (всего исправлений: 1)

Она просто очень старая, сейчас уже все, бобик сдох вроде. Раньше просто была популярная

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

Тяжёлое наследие - старые пердуныпогроммисты с BDE начинали. А там Interbase активно продвигался. А это тот же Firebird.

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

ziemin ★★
()
Ответ на: комментарий от ziemin

IIRC, в начале века mysql многими обоснованно считался dirty-read-безделушкой для сайтов, а firebird имхо был чуть ли не единственным нормальным версионником из бесплатных, который просто работал, не лагал в синке и имел эмбеддед. Плюс борланд, естественно — куча компонент и почти официальная поддержка. Теперь смысла в нем нет.

arturpub ★★
()
Ответ на: комментарий от Black_Roland

Потому я ее так редко встречаю

А вот я наоборот. И причём с ними ещё интегрироваться надо. И только однажды разработчики такой системы мне помогали.

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

Я так подозреваю в руководствах так и писали «<какая-то явно client-side фигня>. Для этого добавим процедуру/триггер...».

ziemin ★★
()

Затем что это офигенная очень компактная, надежная, быстрая и полноценная СУБД, умевшая встраивания, когда еще sqlite в природе не было.
Сравнивать ее можно с postgresql, mssql, oracle, но никак не с недосубд типа mysql и тем более sqlite. Я писал АБС 5го поколения на firebird, при росте нагрузки нижний уровень был параллельно адаптирован для оракла - уперлись в io (шел 2001 год).

handbrake ★★★
()

Инструмент для неё хороший, который IBExpert. Плюшки типа триггеров появились лет на 10 раньше чем в MySQL. Вообщем в 2000-м это уже торт был.

ilovewindows ★★★★★
()
Ответ на: комментарий от handbrake

Помню девелоперы еще ржали над пациентами, которые жаловались на 100% загрузку cpu и объясняли балбесам, что радоваться надо, когда не в io упираешься.

arturpub ★★
()

Какие у нее преимущества?

Интегрированость,дефолтность и традиционность для Delph-ей. Безшовное переключение между серверным и встраиваемыми вариантами работы.

Почему не используют MySQL (MariaDB)

MySQL чисто серверный с всеми вытекающими накладными по администрированию и тасканию за собой. У FB лучше оптимизатор и более широкая поддержка SQL. По крайней мере так думают FB-шники :)

или SQLite

У SQLite очень «свой» подход к многопоточной работе и полностью ее плюшки раскрываются в C-шном интерфейсе. Для тех же Делфей оно доступно только опосредованно через обертки которые значительно режут плюсы и не дают почти ничего чего бы не было у привычного fb.

antares0 ★★★★
()
Ответ на: комментарий от handbrake

что-то на 6 гиговой базе firebird уже успешно падал от несварения, на тамже сервер ныне постгрес ворочает туже базу уже распухшую до 300гб

Deleted
()

Делфисты её почему-то очень любят.

blexey ★★★★★
()
Ответ на: комментарий от mul4

Пичаль. Что я ещё могу сказать? Ничего против firebird я не имею, но этот подход «не знаешь что делать - нахерачь серверную процедуру или, ещё лучше триггер, завязанный на другие процедуры и триггеры...» это пипец.

ziemin ★★
()
Ответ на: комментарий от ziemin

Справедливости ради - это был way to go и все думали что это правильно и универсально. И это до сих пор правильно (спроси Тома из Оракл хотя бы :) ... но _уже_ не так универсально.

anonymous
()
Ответ на: комментарий от anonymous

А «пичаль» у тебя от того что твоё ОНО мыскль научилось в триггеры и процедуры только недавно :-р

anonymous
()
Ответ на: комментарий от anonymous

.

Преимущество у нее только одно - это drop in replacement для Boland Interbase. Так что ты можешь поставит еЯ на современный сервер с современным линуком и выжать IOP'сов ничего не изменив для клиентской части (старых п-нов с Delphi наперевес :))))

anonymous
()
Ответ на: комментарий от anonymous

только недавно :-р

угу. А то, что бусылогика в БД это типа нормально? Я интегрируюсь по следующему алгоритму:

  • Выяснить, что за БД используется. Если БД нет, то это пипец!;
  • Открыть исполняемый файл в виме и узреть пароль к БД в незашифрованном виде... (здесь должен был быть вариант «иначе пипец!», но такого я ещё не встречал);
  • открыть через flamerobin и 0x уеть от мильёна процедур.
  • ...
  • Нихера не профит. Ещё раз многоточие.
  • ...
  • Вот теперь профит.
ziemin ★★
()

Я есть тот динозавр, который использует Firebird и в нём интенсивно применяет хранимки и триггеры. По правде сказать, у этого подхода есть минусы. Но есть у него и плюсы - прежде всего, производительность. Где-нибудь на порядок отличается производительность хранимок на сервере БД против обработки тех же данных в другом месте (хотя это зависит от задачи, конечно же).

Насколько я понимаю, у MySQL довольно грустно с параллельностью. В нём вроде бы недоступны длительные параллельные транзакции, которые и пишут, и читают одновременно. Хотя этого я точно не знаю. Поэтому на вопрос, почему не пользуюсь MySQL, отвечу так: потому что Firebird устраивает и потому что так исторически сложилось.

SQLite же вообще встраиваемая СУБД, а Firebird бывает и серверной, поэтому у них не совсем одинаковые области применения. Что бы я взял в качестве встраиваемой? Не знаю.

Касаемо трудностей, возникающих у тех или иных людей при освоении кода Firebird - знания нужны для работы с любым сервером. Пользуйтесь IBExpert-ом и учите матчасть.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от Deleted

У меня до 20 с чем-то было, уперслись в io потому-что выписки/остатки каждый раз по новой считались + учетная модель (плоскости учета,планы счетов их взаимодействия, полупроводки и их связи с документами) тоже задавалась конструкциями в БД. БЛ, да в БД, но такой подход зря хают, он в БИФИТе, например используется, и вообще круто, когда хряпы с бешенной скоростью проводки чешут. Или выписку SQL хряпы занимающий 3 экрана кода собирает. Только хряпа уже скомпилирована, в отличии от запроса, которому еще предстоит.
Работало стабильно. У людей бывали и сотни гиг. И тоже все нормально. При написании просто есть вещи, которые нельзя трогать (типа IN), кстати, они относятся к любым СУБД, более-менее быстро их оракл, разве что, переваривает и то сколько себя помню - это bad practice и только если ну совсем никак по другому. Нормально спроектированная БД работала очень быстро и стабильно (см выше :). Ну и версионность с генераторами на сладкое. В firebird'е один подвох - бэкап на рестор надо проверять :)

handbrake ★★★
()
Ответ на: комментарий от arturpub

Ну, CPU постоянной проблемой был, особенно учитывая, что тогда у меня, например, стоял особо свежий pIII аж на 866 Мгц. Ядер опять же завались тогда было - целое одно. А проводок больше ляма.

handbrake ★★★
()
Последнее исправление: handbrake (всего исправлений: 1)
Ответ на: комментарий от den73

Звучит как исповедь. Надеюсь ты не выбросился из окна после этого? Ответь!

ziemin ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.