Pull to refresh

Comments 32

Интересно было бы посмотреть MariaDB, особенно в сравнение с MySQL

Тут, для честности, придется сравнивать код, написанный после форка.

Все куски кода приведенные выше, насколько я вижу, были написаны после форка. В MariaDB их нет.
Ну тогда еще Percona Server в то же сравнение надо добавить
Не, это сравнение Percona Server и так покрывает. Там все выше приведенные ошибки должны быть.
однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Можете сказать, как этот внутренний сервер называется?
Да кому он нужен то теперь? Есть же MariaDB
Это только усугубляет ситуацию. Чем дальше, тем меньше между ними будет совместимости.
А зачем между ними совместимость? В первые годы нужна была для облегчения миграции. Сейчас уже не актуальна.
А сравнение mysql и mariadb вы не планируете?
А можно ли статическим анализом отлавливать проблемы с неэффективной реализацией алгоритмов? Что-то вроде «вот тут делается поиск в сортированном массиве за O(n)», «тут у нас список, а надо бы хешмэп» или «а тут реализован Алгоритм маляра Шлемиля» и т.п.
Теоретически, возможно. На практике, очень сложно научить распознавать по коду, что хотел сказать программист. Уж очень много способов написать один и тот-же алгоритм.

Для такой задачи, вообще больше подходят обзоры кода, где старшие товарищи дают хорошие напутствия новичкам.
Обзоры кода требуют наличия высококвалифицированных специалистов, а это дорого. Для этого, собственно и изобрели статический анализ.
Всё верно, примерно так делается подсветка кода, автодополнение, навигация по коду и т.п… мы же ищем ошибки и уязвимости. Тем не менее, у нас есть чуть более 20 диагностик для поиска оптимизаций: можно найти и исправить достаточно серьёзные проблемы.

Но чтоб предлагать заменить один алгоритм на другой, такого нет. Это принципиально другая задача.
При прочих равных Firebird будет догонять Postgre ещё долго и долго по фичам и допустимым нагрузкам, а за это время количество ошибок вырастет не кратно, а экспоненциально и окажется он ниже MySQL.
Его ниша (как потомка Borland) была в эмбеддовке на Delphi, которую без проблем решает SQLite.
ниша InterBase никогда не «была в эмбеддовке на Дельфи». И никогда InterBase и Firebird даже в embedded-режиме не были аналогом файл-сервера SQLite.

А насчет увеличения количества ошибок весьма странный вывод. С такой логикой наоборот, в PostgreSQL количество ошибок должно расти больше всех.
Сейчас объясню свою точку зрения:
По поводу эмбеддовки с Дельфи: Заменить полноценный сервер, как то MS SQL на Windows или MySQL/Postgre оно никогда не могло. Потому и заброшено Борландом. Но у MySQL/Postgre всё весьма грустно по части «носимых» баз, а MS SQL CE имеет весьма грустные ограничения. В паре с какими-нибудь FibPlus и EhLib это смотрелось очень неплохо в своё время, особенно для бедных студентов, ведь можно было сделать прилагу на коленке, а потом прийти с курсовым в училище, показать там что «вот, у меня полноценная СУБД использована, всё по взрослому, с отдельным сервером», т.к. установка и запуск на винде были довольно тривиальные. Но когда речь поднимается про нормальное управление доступами, приличные нагрузки, нормальные бекапы, какие-то фичи сложнее селекта — её начинает резко нехватать. Ещё она частенько ломалась и была свистопляска в версиями, которые не очень-то хорошо работали с драйвером от другой версии. Я имел довольно большой опыт внедрения поделок с этой штукой (причём не только на Windows) и не могу никому её рекомендовать. Уж лучше SQLite, если нужна локальная БД или MySQL, если сеть — эти решения будут быстрее, надёжнее, гибче и функциональнее, чем FB, плюс полно как бумажной литературы, так и сайтов/форумов/конф по всем СУБД, по FB же ещё лет 5 назад был только томик Хелен Бори (до сих пор где-то на даче лежит никому ненужный) и полтора скромных форума.

А на счёт увеличения количества ошибок: чем больше возможностей, тем больше кода и тем код сложнее, и тем сложнее всё это сопровождать и развивать. Соответственно и количество ошибок будет сильно расти. И то что при большом росте Postgre не сильно вырос по количеству ошибок лишь доказывает что это весьма хорошая СУБД.
Обалдеть.
Вы в курсе, что PostgreSQL с SQL в его нынешнем виде появился только в 1995 году? В это время уже был InterBase 4й версии, под хренову тучу платформ, и вовсю использовался (еще с версии 3) на Московской Бирже и в Центре управления полетами.
Поэтому с точки зрения полноценности, как сервера, PostgreSQL в это время с InterBase и рядом не стоял. Это было студенческое поделие, не более того.
А «приличные нагрузки» PostgreSQL начал осваивать-то всего несколько лет назад.

Так что, при всем уважении, позвольте считать ваш коммент ахинеей.

p.s. на всякий случай напомню, что с СУБД вообще я работаю с 1989 года, а с InterBase — с 1994 года. Так что в плане истории мне вот эти сказки заливать не надо.
Я знаю, что некоторые по сей день молятся и на dBase, и на Paradox, особенно в устаревшем софте, который некогда и некому переписывать (не говоря уже про нормально спроектировать и поддерживать), и вообще страшно всё это трогать, но это их проблемы. Я даже лично знаю пару весьма крупных контор республиканского значения и один комбинат, которые всё никак не откажутся от этого кактуса, одна из них ещё недавно виртуалки с DOS6.22 и FoxPro 2.6 крутила ежедневно, чтобы оно хоть как-то работало. Реальность же такова, что InterBase умер, причём не давно, а очень давно (особенно по меркам ИТ) и явно не от того, что он такой хороший и старый (он же не вино), а FB глючный и давно отстал от остальных «более молодых» конкурентов, которые обогнали его просто со свистом по темпам развития, надёжности, безопасности, ремонтабельности и фичам. Это состоявшийся факт. Если хотите его оспорить, приведите более весомые, на сегодняшний день, аргументы, чем ваш стаж, т.к. я тоже ещё ЕС1841 застал и под FB тоже успел поработать/пописать, и под IB (кстати я знаю одну контору, которая тоже ещё недавно его вовсю пользовала для учёта бланков строгой отчётности и это было тоже весьма ужасно). Я откровенно не понимаю ажиотажа вокруг FB и Delphi на постсоветском пространстве.
— вы не знаете, что и когда появилось — InterBase, PostgreSQL, MySQL, и с историей развития тоже пробелы.
— вы пишете про какую-то «свистопляску с версиями и драйверами»
— «сложнее селекта» — ну конечно
И т.д. Теперь вы почему-то упоминаете dBase и Paradox.
И вы совершенно не в курсе, какие системы сейчас нормально обслуживает Firebird — базы в сотни гиг и сотни пользователей, если что.

Да, по некоторому функционалу Firebird отстает от PostgreSQL, но у PostgreSQL с этим функционалом есть ряд проблем (да и с другим функционалом тоже), это ни в коем случае не «идеальный сервер».
Так что наезжать на Firebird не надо. Вам PostgreSQL нравится? Ну и ладно.

Собственно, статья, к которой вы пишете такие комменты, совсем не о том, что вы начали.
Вот только я не писал, когда что появилось. Про свистопляску с драйверами… мне казалось вы должны быть в курсе, учитывая вашу активность по популяризации FB, что у каждой версии FB своя версия fbclient и они не шибко то обратно совместимы. А я это ещё и на Qt собирал/заводил, там это тоже то ещё было удовольствие.
dBase я привёл в пример тому, что многие цепляются за то, что кое как, с болью и скрипом когда-то было внедрено и не хотят ничего менять, оправдывая это всеми правдами и неправдами.

Ну и конечно я не в курсе конкретно ваших кейсов, ваших УМВР и ваших бирж (которыми опять же кроме вас никто не пользуется). Но личный опыт и опыт подавляющего большинства контор (в т.ч. куча статей про инфраструктуру высоконагруженных ресурсов на Хабре) показывают, что FB далеко не самая удачная СУБД и большинство тех контор, которые его когда-то использовали, ушли на другие СУБД явно не от желания добавить себе работы.
И очень хочется почитать реальную статью, что же такого плохого у Postgre есть, что FB якобы уделывает его и, вдруг, становится «идеальным» сервером. Или что такое жизненно важное есть в FB, чего нет у других.

А изначальная претензия была как раз в том, что они сравнивают заведомо более слабую по всем параметрам СУБД и при этом ошибочно пытаются притянуть за уши её как наиболее «безошибочную» — с этим раскладом, с учётом личного опыта, я не соглашусь ни в коем случае.
— вы не писали что когда появилось, но почему-то пишете про «не могло заменить полноценный сервер», «без нормального управления», и прочее.
Я напомню, что нормальным PostgreSQL стал только с версии 8, в 2005 году, а до этого в общем-то его при той нагрузке, на которой InterBase (и уже Firebird) нормально работал, использовать PG было нельзя.
MySQL тоже вышел, собственно, в 2000 году, и сразу завоевал популярность в вебе, при том что у него и sql был убогий, и с транзакциями вообще никак, и т.д.

— если вы не в курсе кейзов, ну так почитали-бы. Вместо этого огульно принижать FB? Помню я эту вашу историю с несчастным QT. Вам просто не повезло с выбором драйвера и инструментов, а в результате Firebird оказался виноват.

— насчет «что плохого есть в PG» — будет такая статья на хабре, пока только собрано от людей, которые и ФБ знают, и PG.
А про «идеальный ФБ» или «ФБ уделывает PG» я ничего не говорил.

— про «заведомо более слабую» — ну опять вы придумываете. Вы же не знаете, какие системы есть на ФБ. Зачем выпячивать свое незнание, на котором вас можно элементарно поймать?
К примеру, одна из десятков известных мне систем на ФБ, средняя — это 200 гиг база и около 600 одновременно активных пользователей. Ваш личный опыт насколько близок к этим характеристикам?
Вот только в 2005 (с ваших слов!) Postgre уже стало нормальным, MySQL тоже, а FB всего 5 лет назад продолжал тормозить и убивать базы. Нам просто не повезло с выбором инструмента в лице FB. С ним было тьма проблем. На том проекте тоже были сотни пользователей и очень много инстансов, недостатка в данных не было. Благо что на самых критичных серверах использовали Oracle и оно хоть как-то шевелилось.
А вы случайно не знаете, почему такой плохой MySQL сразу же завоевал популярность в вебе, а FB до сих пор там никак? А ещё MySQL вышел не в 2000. А Postgre не в 1995.
Так же у меня есть большие сомнения, что вы в курсе моих проблем с Qt (не Quick Time!), а потому «помнить» их не можете.
И у меня для вас есть страшное откровение: 200Гб база это очень мало было уже 5 лет назад, даже для таких чайников как я, а сегодня этой цифрой вообще не смешите. У меня одного за неделю данных больше пролетает в виду специфики текущей работы.
>а FB всего 5 лет назад продолжал тормозить и убивать базы
хватит уже ерунду нести. Где ваши обращения в ремонт баз? Где ваши обращения к нам в техподдержку на тему тормозов? Где ваши обращения по этому поводу хотя бы на форум sql.ru?

А про «тормоза» я вам по секрету скажу — в массе, и не только в отношении Firebird, это заслуга прикладных программистов.

> А ещё MySQL вышел не в 2000. А Postgre не в 1995.
а когда? :-) Вы что, уже пользовались PostgreSQL, в котором SQL не было? До 95 года? К этому времени в InterBase, между прочим, уже давно был полный синтаксис join по стандарту SQL92, в отличие от других коммерческих SQL-серверов.

Полагаю, на этом дискуссию имеет смысл закончить.
Простите?! С добрым утром! А при чём тут ВАША тех.поддержка? Вы вообще кто? Вы что, всё это на личный счёт принимаете? Тогда понятно, ну извините, лично к вам и к вашей личной конторе я не имею никакого отношения. Так что да, нет смысла продолжать, если мы друг друга даже понять не можем.
я — это ibase.ru. Техподдержка по ИБ и ФБ в России с 2002 года.
Если не нравится — обращались к разработчикам ФБ? Нет? Ну и до свидания.
нет. Я часом тот самый, кто сделал первый сайт про InterBase в России — ib.demo.ru, а потом уже и ibase.ru.
С разработчиками Firebird, разумеется, знаком уже много лет.
Да, Interbase был хорош для тех лет, 1995 года. А потом Борланд стал заниматься непонятно чем, и упустил шанс на нормальное развитие хорошего продукта.

>А «приличные нагрузки» PostgreSQL начал осваивать-то всего несколько лет назад.

Несколько — это 10+, вероятно. Биллинги уже тогда делали на постгресе.
Sign up to leave a comment.