Доступен (https://www.firebirdsql.org/en/news/firebird-3-0-2-sub-relea... корректирующий релиз реляционной СУБД Firebird 3.0.2 (https://www.firebirdsql.org/en/firebird-3-0-2/), продолжающей развитие кода БД InterBase 6.0, открытого в 2000 году компанией Borland. Firebird распространяется под свободной лицензией MPL и поддерживает стандарты ANSI SQL, в том числе такие возможности, как триггеры и хранимые процедуры.
Кроме устранения ошибок (https://www.firebirdsql.org/file/documentation/release_notes... и улучшений (https://www.firebirdsql.org/file/documentation/release_notes... в Firebird 3.0.2 устранена уязвимость (http://tracker.firebirdsql.org/browse/CORE-5474), которая позволяет аутентифицированному пользователю повысить свои привилегии и выполнить код с правами рабочего процесса СУБД через манипуляции с UDF-функциями (User Defined Function), независимо от содержимого настройки 'UdfAccess = Restrict UDF'. Пользуясь тем, что fbudf.so динамически связывается с libc, эксплуатация сводится к выполнению следующих команд:DECLARE EXTERNAL FUNCTION EXEC cstring(4096), integer RETURNS integer BY VALUE ENTRY_POINT 'system' MODULE_NAME 'fbudf' ;
select first 1 EXEC('touch /tmp/proof') from some_table;
Из улучшений (https://www.firebirdsql.org/file/documentation/release_notes... в Firebird 3.0.2 можно отметить портирование (http://tracker.firebirdsql.org/browse/CORE-3885) для платформы Android и устаревших систем на базе CPU Motorola 680000 (https://ru.wikipedia.org/wiki/Motorola_680x0) , возможность (http://tracker.firebirdsql.org/browse/CORE-1095) использования выражения SELECT в качестве параметра оператора BETWEEN, обеспечение сборки на платформе Linux с опцией "--enable-binreloc", существенное увеличение (http://tracker.firebirdsql.org/browse/CORE-5434) производительности транзакций только на чтение, поддержка (http://tracker.firebirdsql.org/browse/CORE-5257) вложенных ключей в конфигурации плагинов.URL: https://www.firebirdsql.org/en/news/firebird-3-0-2-sub-relea.../
Новость: http://www.opennet.me/opennews/art.shtml?num=46256
Хоть какой-то юниксовый софт ее использует? Или эту БД на *nix ставят только для использования ее виндовым софтом?
ее часто в встроенном режиме юзали под вендой когда-то
Здесь возникает резонный вопрос: чем FireBird лучше SQLite на однохостовой системе?
А чем тот-то SQLite лучше? :) Просто многие почему-то пытаются свое личное мнение выдать за какой-то стандарт.
в sqlite очень урезаный alter table, например
Тем что полноценная, и позволяет однообразно решать задачи в т.ч. с масштабированием.
лично мое мнение: ничем не хуже, даже лучше
объясняю: на однопользовательской системе равнозначны, но, при необходимости, очень легко мигрируется на многопользовательский режим.
Да. Не поверишь. Для ФССП редсофт (у них файрберд носит название "Ред База Данных") написал на джаве и внедрил (под centos 5/6) свое пoдeлие по всей стране на файрберде. Глючное гуано, с неоптимизированными запросами, база тормозит и разрастается до десятков гигов за месяц, требуя постоянного обслуживания в рученьки. И все это за тонны денег. И такие примеры в госструктурах постоянно. "Экспертов в России нет - есть только разные уровни некомпетентности" (с)
Странно... я тоже много чего писал с использованием Firebird, и дофига копий софта было, но никаких проблем Firebird не приносил. Вполне себе стабильная, шустрая и удобная в работе СУБД.
Кстати работающая параллельно MySQL 5 иногда рушит таблицы, приходиться восстанавливать :(
> я тоже много чего писалу вас не хватает образования погогнокодить. ещё небось и ни кусочка с мутных форумов не накопипастили
> Странно... я тоже много чего писал с использованием Firebird, и дофига копий
> софта было, но никаких проблем Firebird не приносил. Вполне себе
> стабильная, шустрая и удобная в работе СУБД.
> Кстати работающая параллельно MySQL 5 иногда рушит таблицы, приходиться восстанавливать
> :(Так проблема то не в инструменте :)
>"Экспертов в России нет - есть только разные уровни некомпетентности" (с)Из России пишешь, некомпетентный наш?
И сразу виновата Россия и Firebird :)<криворукий ламер/засланный казачёк/ребёнок без головного мозга> написал за миллион денег на <СиШарпе/Джаве/Ассемблере> мега прогу. Глючит, запросы неоптимизированные, база тормозит (старался специально), разрастается террабайтами в день (дурное дело не хитрое). Лярды денех!
Ура - Виновата Россия и эксперты!
> Ура - Виновата Россия и эксперты!Тебе видимо не приходилось сталкиваться с тем бардаком, который творится в госструктурах? Загляни как-нибудь, поработай там, и ты будешь петь ровно те же песни: распил, откат, некомпетентность. Система устроена таким образом, что там ничего кроме этого нет и быть не может.
Я вообще-то не про то.
Я не спорю, что в госструктурах всё плачевно и много раздолбаев.-
Внимательно читаем сообщение bruges:
"Для ФССП редсофт .. написал на джаве и внедрил .."..Всё тормозит у него.. База разрастается.. Требует постоянного обслуживания..
И вывод - "Экспертов в России нет .."
-
Так и хочется посоветовать ему полечиться.
Я лично писал программы, службы сбора и обработки данных с файрбёрд 2.5
Тормозило там, где надо. Запросы надо уметь оптимизировать. База не разрастается без причины. Постоянного обслуживания требует только в том случае, если любят тыкать резет (но тут уже мало что поможет).-
<Сарказм от программиста> В госструктурах всё плохо и только программисты там белые и пушистые, с прямыми руками и горячим сердцем.
>любят тыкать резетFirebird не умеет в ACID? Т.к. у той же BDB, тех же веков выпуска, имеются защиты от ресета, в том числе восстановление из журнала.
Ну, и если следовать логике, что виноват во всем резет, то это лишь подтверждает сарказм про некомпетентность.
Я тебе сейчас страшную вещь скажу. firebird и даже bdb пишут не напрямую на диск, а через файловую систему. И насколько мне известно, пока ни одна файловая система в rw не обладает 100% защитой от reset. Чем тебе поможет журнал, если обнулится или замусорится файл с ним или самой БД?
>Чем тебе поможет журнал, если обнулится или замусорится файл с ним или самой БД?Журнал для того и сделан, что БД остается чистой. В то время как при возобновлении работы БД сравнивает последние данные с записями в журнале и в случае расхождения приводит все в порядок. Если журнал будет неполным из-за ресета, то коммит не пройдет в файл БД. Совсем.
Это может казаться неидеальным решением (а какое ты можешь предложить?), однако, вполне рабочим. Иди, читай дальше как устроены современные БД, можешь почерпнешь что нового и не будешь "срывать покрывала" с очевидных вещей :)
Еще раз для танкистов. Если у тебя файл БД обнулился, то чем тебе поможет журнал? Как ты будешь откатывать изменения, если транзакция уже начала применяться к БД, а журнал потерян?
>Если у тебя файл БД обнулился, то чем тебе поможет журнал?Журнал поможет, если в журнале есть все данные для восстановления. Если журнал начинается с точки Х, а БД началась с точки Х-100500, то журнал, естественно, не спасет. См. ответ ниже, я там тебе подробно все изъяснил.
>Как ты будешь откатывать изменения, если транзакция уже начала применяться к БД, а журнал потерян?
Не совсем понятно, что имеется ввиду, точнее, не ясно какой момент БД подразумевается. В случае, если журнала нет, а БД есть и точкой времени для описываемой ситуации является начало работы БД, то имеется несколько развязок (зависит от конфигурации):
0. Во всех случаях БД сообщит, что файл журнала был нарушен.
1. БД может не стартовать, т.к. такая ситуация является критической (требует вмешательства DBA).
2. БД может стартовать в штатном режиме, если имеются НЕповрежденные копии журнала.
3. БД может стартовать в штатном режиме и восстановить работу журнала. Если последнее не удастся сделать, то опять вилка: либо критическая ситуация, либо продолжение работы (пофигизм).В случае, если журнал теряется при работающей БД, то тогда могут применяться различные методики: от пофигизма до полной остановки БД или перехода в режим RDONLY. В любом случае, это критическая ситуация, даже если тупо закончилось место на диске. Задача DBA _снизить_ риск потери всех данных до минимума, а не пытаться создать _идеальную_ систему (кои ты увидел в raw-дисках ^_^). Она в любом случае будет не идеальной, т.к. даже в случае кластера может накрыться вообще _всё_. Тут-то и спасут фулбэкапы :)
> Журнал поможет, если в журнале есть все данные для восстановления.То бишь на практике никогда
> Не совсем понятно, что имеется ввиду, точнее, не ясно какой момент БД подразумевается.
Если тебе непонятно, то ты спрашивай, а не вываливай кучу инфы не по теме.
Объясняю. Транзакция состоит из нескольких атомарных действий. Эти действия записываются в журнал и начинают применяться к БД. В случае сбоя идет откат транзакции на основе записей в журнале. А теперь представь, что транзакция частично выполнилась и тут даванули на reset. После загрузки оказалось, что файла журнала больше нет. Как ты собираешь откатить или завершить транзакцию?
>А теперь представь, что транзакция частично выполнилась и тут даванули на reset. После загрузки оказалось, что файла журнала больше нет. Как ты собираешь откатить или завершить транзакцию?Для таких случаев существует DBA. Серьезно. Если у тебя система, а не тупо БД-хранилка, то в этом случае тебе нужно прописать алгоритм а) обнаружения неполадки; б) алгоритм восстановления данных в файле БД. Последний пункт может решаться через вытягивание с удаленного сервера файла журнала, при необходимости фулбэкапа и далее вывода на экран окошка "Восстановление БД. Ждите...".
Я понял, что ты не веришь в силу журналов, но это, опять же, твоя некомпетенция/лень/малозаплатили.
> Для таких случаев существует DBA.Угу, в организациях, где сотрудники жмут на reset почем зря. Вернись в реальный мир, Нео.
> Я понял, что ты не веришь в силу журналов, но это, опять же, твоя некомпетенция/лень/малозаплатили.Нет, ты ничего не понял. Я не верю в магию, а в полезности журналов не сомневаюсь. Да ты собственно и не хотел понять, ты лишь хотел покрасоваться, поэтому и не удосужился читать внимательно. Бывай, эксперт.
>ты лишь хотел покрасоватьсяНет :) Это ты хотел покрасоваться своими знаниями о raw-дисках.
>Бывай, эксперт.
Зовите меня просто любитель. На роль эксперта я не выдвигался, а просто напомнил про журналы, кои у всех работают, _кроме_тебя_.
>Угу, в организациях, где сотрудники жмут на reset почем зря. Вернись в реальный мир, Нео.Это уже умение вести наШбизнес. Восстановление из журнала: 500 руб/час. Восстановление из фулбэкапа: 1000 руб/час. Написание автоматической системы, содержание бэкапов в облаке: 100 000 руб.
С другой стороны, все прописывается в договоре и ТЗ. И это уже разговор про иную компетенцию.
Сам ресет может зафигачить не то чтобы БД на 10 000 руб., он может затереть файлы на миллионы рублей. И тебя это не должно волновать. Твое дело рубить бабосы с идиотов. Вот и руби их :)
Кроме того, твой идеализм не позволяет понять всей концепции. Не нужно восстанавливать транзакцию. Нужно вернуть БД в рабочее состоянии. Пусть даже потеряются наработки за весь день! Это лучше, чем потерять вообще всё. Есть журнал за последние два дня? Хорошо, раскатываем БД до этого момента. Нету журнала? Ок, откатываемся на последний месяц.Нету идеальных систем. И ты не построишь не то чтобы хоть какую-то адекватную систему с _приемлимым_ уровнем потерь, ты вообще никакой системы не сделаешь со своим перфекционизмом/идеализмом.
Все. Читай, разбирайся. Или тупо забей болт. Ты ж гений, а кругом...
>Если у тебя файл БД обнулился, то чем тебе поможет журнал?В такой ситуации с сабжем на борту возникает дополнительная рулетка :) Их бэкап - притча и интернетах :)
Восстановить из бекапа и накатить редо-лог, журнал по нашему.
И более того. В современных БД используется не один журнал, а несколько. Несколько на разных физ. дисках, если делать по феншую.
Как то за десять лет администрирования ни разу не видел подобного, а ведь конторки были не чета тем, где reset жмут по чем зря. Reset в твой феншуй как-то укладывается или ты уже забыл, о чем речь шла?
>Как то за десять лет администрирования ни разу не видел подобногоЭто твои личные трудности. Объясняю на пальцах. Современный журнал это не просто один файл. Это _система_, которая может работать с файлами, а может и не работать с ними, например, журнал может быть в ОЗУ.
Журнальные файлы могут работать в режиме round-bobbin, в таком режиме транзакции пишутся по очереди, сначала в один файл, затем в другой, затем в третий, потом снова в первый. Альтернативно, журнальные файлы могут работать в режиме контрольных точек, в таком случае, в зависимости от левой пятки DBA, один (или несколько) файлов находятся в режиме RW, а остальные в RDONLY (они даже могут быть не открыты БД). И в том и другом случае обеспечивается определенный уровень надежности от сбоя -- откат произведется на самую последнюю верную транзакцию.
Поверх этого, накручивается система сжатия и архивирования журнальных файлов, т.е. посути 2й вариант выше, но предназначен для копирования журнальных файлов на внешние хосты (сервера) или внешние устройства (флешки, ленты и т.п.).
Журнальные файлы и их архивы активно применяются в современных БД по еще одной важной причине: в то время как файл БД может быть невероятно огромным, журнальные файлы (особенно в сжатом виде) весят _намного_ меньше. Стандартной практикой является фуллбэкап раз в 7-30 дней, а бэкапы журналов могут быть хоть по-часовыми (зависит от кол-ва коммитов).
Итого, сам смысл журнала никуда не девается. Это промежуточное звено между началом коммита и конечной записи его в файл БД. На основе расхождений данных и обеспечивается защита от сбоев (не 100%, т.к. диск может рассыпаться ... и без возможности восстановления). Другие технологии вроде полного бэкапа, UPS, рейды и т.п. решают _совершенно_ иные задачи (хоть и имеющие общую цель -- снизить риск утери _всех_ данных).
Поэтому, твой довод про то, что БД работает на файловом уровне не верен в корне. Если бы БД работала в raw-режиме, то ее не спасет тот же самый ресет, т.к. атомарность записи на диск не зависит от того как работает БД, а зависит от кол-ва данных, которые содержаться в транзакции. Тут-то и проявляется некомпетентность, т.к. считать что одна транзакция есть один insert это все что нужно. В сложных системах происходит десятки или даже сотни insert'ов в _одной_ транзакции. И если такая транзакция накроется, то и все insert'ы не попадут в файл БД и все будет тип-топ (т.е. не надо "до-инсерчивать" потерянные инсерты, как было бы в случае одиночных коммит=insert'ов).
Зачем ты вывалил этот поток сознания, когда я тебя спрашивал совсем про другое? Похоже ты вообще за дискуссией не следишь, а только ищешь способ выпятить свои мегазнания.
Ах, да. Сорву покрывало для тебя. Для систем, где важно не терять данные и предотвращать потерю данных при записи на диски, используется UPS. Даже для рабочих станций, если в этом есть действительная необходимость. Либо BBU для рейд-контроллеров, который заботится о несчастных.Ты доволен своими скромными познаниями? :)
Ну а теперь подумай хорошенько, в пользу чьего тезиса ты сейчас привел аргумент.
У него специальный UPS же! Оно отключает reset при подключении :)
Я 4 года работал в госструктуре. Абсолютно тоже самое, что и в коммерческих структурах.
> Я 4 года работал в госструктуре. Абсолютно тоже самое, что и в
> коммерческих структурах.я думал этого никто не скажет. только напомню, что в других тредах стоит повальный вой про эффективных менеджеров, уродов-маркетологов и прочее. но стоит детям услышать про госструктуры, праведный гнев отключает память и большинство библиотек аналитики.
Коммерческие структуры разные, а вот все что связано с отечественными госорганами - феерическое гoвнищe.
Что вышеупомянутое редсофтовское поделиe, что АРМы которые и под виндой-то еле работают, что отечественные криптосредства (не к ночи будут помянуты) и прочие выкидыши импортoзамещения.
Вы правы, Firebird не при чём.
Наверное, неоптимизированные запросы и разрастающаяся база - это вопрос к архитектору и программистам, а не к СУБД ? :) А про уровень некомпетентности в России - люди везде одинаковые, даже "эксперты" лепят детские ошибки каждый день, разница лишь в том, что опытный программист свою ошибку быстрей найдет и исправит.
> Для ФССП редсофт (у них файрберд носит название "Ред База Данных") написал на джаве и внедрил (под centos 5/6) свое пoдeлие по всей стране на файрберде. Глючное гуано, с неоптимизированными запросами,1С-то видел под линуксом? что там с оптимизацией? А контора вполне себе коммерческая.
> 1С-то видел под линуксом? что там с оптимизацией? А контора вполне себе коммерческая.Там даже не столько глюки платформы (хотя и их никто не отменял, да). Там, судя по отзывам коллег, которые с этим работают, в конфах сплошь и рядом творится такой АдЪ, что удивляешься, как оно вообще хоть как-то работает.
> Там даже не столько глюки платформы (хотя и их никто не отменял,
> да). Там, судя по отзывам коллег, которые с этим работают, в
> конфах сплошь и рядом творится такой АдЪ, что удивляешься, как оно
> вообще хоть как-то работает.О том и речь. Плюс когда видишь запросы к постгре закрадывается подозрение что понятие оптимизация и название PostgreSQL до сих пор в разных галактиках. Ещё веселее с "плагинами". Разработчики в принципе не очень представляют, что 1С может работать не на винде, с теми же слэшами в путях такой заметный цирк. И никаких госконтор, да.
>>Там, судя по отзывам коллег, которые с этим работают, в конфах сплошь и рядом творится такой АдЪ, что удивляешься, как оно вообще хоть как-то работает.Ад там в основном как раз франчи и интеграторы разводят. Те что от 1С идут - весьма ничего.
Если Apache+PHP считается юниксовым, то да, используется.
Ещё в 2004 году, помнится, участвовал в разработке складской системы.
FireBird у нас тогда крутился под FreeBSD - и надо сказать, вполне себе нормально крутился.
LibreOffice Base вроде может её в качестве бэкэнда
> LibreOffice Base вроде может её в качестве бэкэнда% pkg info -d libreoffice-5.2.5_5 | grep firebird
firebird25-client-2.5.6_2
>БД InterBase 6.0 ... 2000 году ... BorlandДа это просто празд^W deprecated legacy какой-то!
>>БД InterBase 6.0 ... 2000 году ... Borland
> Да это просто празд^W deprecated legacy какой-то!С учётом того что кода от борланд уже не осталось (был полностью переписан) :), а идеи там вполне себе адекватные были...
Хорошая версионно-ориентированная и транзакционная "карманная" СУБД. В отличие от хипстерни MySQL.
уже не актуально - современные версии mysql вполне себе СУБД, те, что были до 5.5/5.6, спору нет, были незнамо чем
в 8.0 (5.8 по-старому) оракель обещает повыбрасывать myisam в раздел неиспользуемых и не поддерживаемых
я даже пропустил, что третья версия субд вышла, думал до сегодняшнего дня, что вторая ещё
зря пропустили, там существенный прорыв по фичам и архитектуре с полным ACID (теперь)
Хорошая, мощная СУБД. Использовал её в части проектов. После mySQL и Interbase она показалась совершенством. А вот с MsSql после Firebird было противно работать, излишне усложнено и запутано всё, а скорости больше не стало.
Вот правда версии 3.0 ждал ещё году этак в 2010, но с финансированием у них туго.
п.с. любая субд может быть отвратительной если не знаешь SQL и тонкости работы с самим сервером БД.
Есть даже недобиллинг на этом мамонте.. вернее он вообще ни ынтербейзе.. от мутных продаванов https://www.embarcadero.com/ru/products/interbaseСам недобиллинг http://www.abacs.ru/
Цены и базы и биллинга просто умиляют.
Автору данного поста задан в личную почту вопрос с запросом аргументов критики
биллинговой системы Abacs. Полгода ждем ответа.В ответ тишина. Трусоват однако..
Руководитель отдела разработки бллнговой системы Abacs Сугак Сергей.
> Автору данного поста задан в личную почту вопрос с запросом аргументов критики
> биллинговой системы Abacs. Полгода ждем ответа.В ответ тишина. Трусоват однако..
> Руководитель отдела разработки бллнговой системы Abacs Сугак Сергей.Пфф смешно. Честно смешно. на тему чего мне "трусить"?
По делу сам подход к разработке не масштабируемый,а многие методы морально устарели.
А уж про хроническое неиспользование индексов и уверения что индексы не нужны. Заявления что тормоза у Вас из-за плохого сервера (аха ибм блейд с 10 рейдом аппаратным из 4 15к дисков), и то что там вместо винды линукс и ставьте обязательно винду вообще было грустно слышать, если честно. И как в последствии выяснилось дело всё таки оказалось ... ПРАВИЛЬНО..в базе, которая обросла грязью, потому что GС там если и есть то чисто символичный...Скажем так - уже давно не наблюдал необходимости делать полный дамп/ресторе базы данных, на том же поцгресе.. той же перконе.
А здесь базка всего-то в 11 гиг размером и еле-еле ползала, пока не dump/restore ей сделал. На
Хинт - root@db:~# du -sh /var/lib/mysql
42G /var/lib/mysql
и никаких тормозов нет, без всяких dump/restore. При том что эта базка крутится вообще на обычном сервере supermicro с 10 MD-рейдом.Далее - репликацию она не умеет от слова совсем никак. А уж про то как данные выгружаются в радиус просто молчу.
И правда смешно.. Это пишет человек,спец во всех областях,ответственный за администрирования именно этого экземпляра СУБД ? Год то страдал,то щеки надувал. А надо только было
прочесть про администрирование сделать бэкап - ресторе. Про переход на другую СУБД. Можно. Только платить за это автор будет сам ?
Мимо.Я не занимаюсь администрированием субд Вашего биллинга от слова совсем.
Что и говорил чуть выше..что ibase/firebird не годятся для серьёзного применения.
Назовите мне в какой ещё базе данных нужно делать backup/restore раз в месяц что бы оно не тормозило на копеешном объёме информации (11 гиг) и это является штатной процедурой для нормальной работы?
Подсказываю - sqlite и то достаточно VACUUM; REINDEXНу и да.. Чего де Вы до этого 3 года молчали пока с Вами работал более лояльный сотрудник К Вам, зато убеждали что это сервер плохой и linux в частности?
По поводу платить - тоже мимо кассы. Я Вам указал на конкретные тех недостатки Вашего решения и костыли и подпорки в работе сервиса.
> Про переход на другую СУБД. Можно. Только платить за это автор будет сам ?Второй вариант -- платят те, кому вы предлагаете ещё и на винде это вздымать. Или не.
По дефолту эта база не дырка, а очко.
По дефолту многие базы имеют настройки такие, чтобы завестись на самом поганом железе... к примеру Firebird и Postresql одни из них...
> По дефолту многие базы имеют настройки такие, чтобы завестись на самом поганом
> железе... к примеру Firebird и Postresql одни из них...Firebird по дефолту дает возможность просматривать удаленно файловую систему. Как это называется?
Можно пример? лучше пруфлинк
Очень нужны новые недекларированные возможности FB!
>Firebird по дефолту дает возможность просматривать удаленно файловую системуЭто как? Можно структуру папок/файлов на сервере запросом select * from что-то_там вернуть? Такого даже Оракл не может по-моему штатно, если только хранимые процедуры на яве не вызывать. Ну да ладно, увидишь ты названия каких-то файлов - что это даст?
> Это как? Можно структуру папок/файлов на сервере запросом select * from что-то_там
> вернуть?Не, вендузоед, только мамок/файлов.
>Не, вендузоедDirectory сущ.
справочник, каталог
указатель
(pointer)
дирекция
(directorate)
директория, папка
(folder)
root directory — корневая директория
directory tree — дерево папок
И в чем я неправ, переводя термин Directory как общепринятое "папка"?
Даже не так, если Directory - это не папка, то почему тогда в твоем DE у нее значок в виде папки? :)
> Даже не так, если Directory - это не папка, то почему тогда
> в твоем DE у нее значок в виде папки? :)В каждой иконе папку видишь, сиротка?
В каждом твоем комментарии вижу оскорбление, а по сути вопроса (как просмотреть список файлов на сервере с клиента через Firebird и что это даст) никто никаких комментариев не дал.
> И в чем я неправ, переводя термин Directory как общепринятое "папка"?С точки зрения перевода неправ, так как "папка" это "folder", а "directory" это "каталог". Но смысл для объектов файловой системы один и тот же, так что в этой области они синонимы( хотя некоторых недалеких личностей бесит использование термина "папка", так как они его ассоциируют с виндой). В других областях IT синонимами они не являются, например directory server/service никак не может быть заменен на folder server/service.
Сравнивать безсерверную SQLite и серверную FireBird, конечно, нельзя. На мой взгляд, при 3-5 клиентах на чтение и 1-2 на запись (уровень отдела) - эти базы равны и примерно соответствуют юзекейсу того же MS Access. При этом будет правдой сказать что SQLite - самая быстрая из всех баз данных на чтение, примерно на 50%-200% быстрее на тяжелых запросах с индексами. И это не IN-MEMORY.Встроенный в LibreOffice Base движок активно пилится под FB3.Х, и у него хорошее будущее, т.к. встроенный сызмальства в Base HSQLDB (100% Java), мягко говоря, странен. Ни одного успешного массового продукта на HSQLDB не появилось, хотя попытки были, например http://plazma.sourceforge.net/frameaction.php?lng=en&page=index
Кстати, по FireBird прекрасно переведен на русский мануал по 2.Х/3.Х - читать-неперечитать. Это дает неслабое конкурентное преимущество.
> Кстати, по FireBird прекрасно переведен на русский мануал по 2.Х/3.Х - читать-неперечитать.Мне интересно, а многие не в курсе кем он пилится, и где вопросы задавать если что, я бы понял если бы иностранцы не знали, но exUSSR-то ;)
> т.к. встроенный сызмальства в Base HSQLDB (100% Java), мягко
> говоря, странен. Ни одного успешного массового продукта на HSQLDB не появилось,
> хотя попытки были, например http://plazma.sourceforge.net/frameaction.php?lng=en&page=indexВы путаете LibreOffice с Apache OpenOffice. В LibreOffice никакого движка HSQLDB нет, и от Java сборка пакета libreoffice не зависит.
http://www.freshports.org/editors/libreoffice/
http://www.freshports.org/editors/openoffice-4/
> В LibreOffice никакого движка HSQLDB нет, и от Java сборка пакета libreoffice не зависит.Ну, не знаю, зависит или нет, но это тогда что?
http://imgur.com/a/wBiO1
>> В LibreOffice никакого движка HSQLDB нет, и от Java сборка пакета libreoffice не зависит.
> Ну, не знаю, зависит или нет, но это тогда что?
> http://imgur.com/a/wBiO1У меня поле выбора встроенной базы данных не содержит списка движков СУБД.
Слева в "Шагах" представлено 3 пункта, а не 2, как на картинке.
1. Выбор базы данных
2. Настройка подключения к dBASE
3. Сохранить и выполнить
В "Выбор базы данных" можно выбрать "Соединиться с существующей", где из выпадающего списка выбрать:
Адресная книга Thunderbird/Icedove
Электронная таблица
dBASE
Текст
MySQL
ODBC
При выборе из этого списка того или иного представления БД меняется количество пунктов в "Шагах". Например, для MySQL можно выбрать Соединение через ODBC (Open Database Connectivity) или через JDBC (Java Database Connectivity) - в последнем случае используется Type 4 драйвер com.mysql.jdbc.Driver, нужно ввести Имя БД, Сервер, Порт (по умолчанию: 3306).
При попытке выбора ODBC и выбора Имени ODBC источника данных появлется предупреждение, что библиотеку libodbc.so.1 невозможно загрузить. (Видимо снёс случайно, когда чистил несущественные зависимости).
> У меня поле выбора встроенной базы данных не содержит списка движков СУБД.Вендузятник должен страдать.
iZEN - OpenOffice|LibreOffice имеют встроенный движок HSQLDB. LibreOffice, после активизации экспериментальных возможностей, - еще и FB2.6.JAVA в OpenOffice|LibreOffice используется часто и густо: во многих Wizards, шаблонах, некоторых макросах, системе проверки грамматики LanguageTools итд. То есть без JAVA использовать офис можно только для нетленки вида заявлений из 3-х строк. За слова отвечаю.
> iZEN - OpenOffice|LibreOffice имеют встроенный движок HSQLDB. LibreOffice, после
> активизации экспериментальных возможностей, - еще и FB2.6.
> JAVA в OpenOffice|LibreOffice используется часто и густо: во многих Wizards, шаблонах,
> некоторых макросах, системе проверки грамматики LanguageTools итд. То есть без JAVA
> использовать офис можно только для нетленки вида заявлений из 3-х строк.
> За слова отвечаю.Не соглашусь насчёт LibreOffice.
Cпециально снёс пакет Java SE JDK:% pkg delete -f openjdk8-8.121.13
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):Installed packages to be REMOVED:
openjdk8-8.121.13Number of packages to be removed: 1
The operation will free 164 MiB.
Proceed with deinstalling packages? [y/N]: y
[1/1] Deinstalling openjdk8-8.121.13...
[1/1] Deleting files for openjdk8-8.121.13: 100%Вот что предлагает установить и апгрейдить portmaster:
===>>> The following actions will be taken if you choose to proceed:
Upgrade ru-libreoffice-5.2.5 to ru-libreoffice-5.2.6
Upgrade libreoffice-5.2.5_5 to libreoffice-5.2.6
Install archivers/p5-Archive-Zip
Install databases/unixODBC
Install devel/mdds
Install devel/ucpp
Install graphics/sane-backends
Install net-mgmt/net-snmp
Install graphics/vigra
Install graphics/OpenEXR
Install graphics/ilmbase
Install science/hdf5
Install science/szip
Install math/glm
Install textproc/gsed===>>> Proceed? y/n [y]
- у LibreOffice нет никаких завязок на Java SE.
iZEN - вы всерьез считаете отсутствие зависимостей при установке гарантией отсутствия таковых при эксплуатации ПО? Просто откройте BASE и попробуйте создать Таблицу, Запрос, Отчет в режим Дизайна. Без JRE/JSE не выйдет.
> iZEN - вы всерьез считаете отсутствие зависимостей при установке гарантией отсутствия таковых
> при эксплуатации ПО? Просто откройте BASE и попробуйте создать Таблицу, Запрос,
> Отчет в режим Дизайна. Без JRE/JSE не выйдет.Да, вы правы. БД создать не получается. (Да мне и не нужно - главное что текстовый (Writer) и табличный (Calc) процессоры работают; есть возможность смотреть и редактировать презентации (Impress); делать несложные рисунки (Draw). По зависимостям для этого Java SE не требуется. А когда потребуется - в курсе).
Не совсем понятно зачем ещё одна свободная СУБД в нише PostgreSQL пока есть сам PostgreSQL. Есть ли у Firebird какие-то преимущества или особые случаи при которых она даёт какой-либо выигрыш?
> Не совсем понятно зачем ещё одна свободная СУБД в нише PostgreSQL пока
> есть сам PostgreSQL. Есть ли у Firebird какие-то преимущества или особые
> случаи при которых она даёт какой-либо выигрыш?Есть, скорость записи, простота обслуживания, качество оболочек для работы с БД ( сравнивая IBExpert с поделками под pg, которые чуть ли не на Electron-е ;) ).
> Не совсем понятно зачем ещё одна свободная СУБД в нише PostgreSQL пока
> есть сам PostgreSQL. Есть ли у Firebird какие-то преимущества или особые
> случаи при которых она даёт какой-либо выигрыш?Ну и с блобами более менее нормально работает.
>>Есть ли у Firebird какие-то преимущества или особые случаи при которых она даёт какой-либо выигрыш?Быстрее на простых запросах. Очень хорошо ведет себя на слабом железе.
Firebird по сравнению с PG имеет почти "нулевое" администрирование.
Но при активных пользователях >30...50 - PosgreSQL выходит в лидеры по масштабируемости.
Ну вопервых, Interbase(Firebird) появился раньше чем Postgree :)
Так что зачем Postgres, если уже был Interbase ?
Я бы сравнил Firebird с маленьким автомобилем, а Postgree с карьерным самосвалом.
Можно конечно и на карьерном себе дрова привезти или мешок картошки из подвала но зачем ?
А Firebird очень прост и быстр для своих задач. Хотя тут сравнение не очень верно, т.к. позволяет работать и с огромными массивами данных тоже. Но у PostgreSQL всё-же арсенал средств шире.На мой взгляд у Firebird стоимость вхождения много ниже, и начать работать проще. Ничего за собой не тянет фактически для встраиваемого варианта достаточно одного файла библиотеки, одного файла БД и можно работать. Жрет минимум памяти. Но если нужна производительность арсенал средств для её увеличения есть.
А у PostgreSQL нужен сразу большой паровоз, только чтобы запуститься.
Не соглашусь с флеймомм выше - у Firebird есть всё необходимое для обеспечения надежности работы БД при отключениях. Сам этим занимался долгое время.