Как стать автором
Обновить

Комментарии 32

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

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

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

Можете сказать, как этот внутренний сервер называется?
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 года.
Если не нравится — обращались к разработчикам ФБ? Нет? Ну и до свидания.
Вы часом не из разработчиков ли FB?
нет. Я часом тот самый, кто сделал первый сайт про InterBase в России — ib.demo.ru, а потом уже и ibase.ru.
С разработчиками Firebird, разумеется, знаком уже много лет.
Да, Interbase был хорош для тех лет, 1995 года. А потом Борланд стал заниматься непонятно чем, и упустил шанс на нормальное развитие хорошего продукта.

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

Несколько — это 10+, вероятно. Биллинги уже тогда делали на постгресе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий