olegbank, ты не поверишь но в 99% подключение к любой БД происходит одинаково.

olegbank,

Тут поищи http://mvnrepository.com

Alexey TominBlazkowiczпропущено...

Не на много. В чем-то лучше, в чем-то совсем плох. Но я же не только на MySQL указал ;)

HSQL оставил впечатление чего-то встроенного, хотя есть SQL и выделенная база.
Postgres хороший, но очень большой. К нему админ нужен. А FB поставил и забыл.
Расуждаю только о том,что пробовал :)

Остальное так, слышал:
SQLite - inline
JavaDB _вроде как_ тоже инлайн.
MariaDB - вроде тот же MySQL вид сбоку.

В целом- у FB есть своё место среди БД.
Жесткое основание использовать HSQL, JavaDb(он же Derby ЕМНИП) продиктовано
попыткой собрать и передать коробочный продукт где БД встроена в приложение
и так-же платформенно близка. Ее легко распространять и поднимать стартапы.
В некоторых случаях mvn install собирает и скачивает все зависимости и все работает.

Из недостатков я-бы выделил ограничения на размер (в In-memory обычно не кладут
крупные хранилища) и отсутствие внятной политики бекапов.

Posgres, MySQL хорош тем что он уже изначально заточен под работу с бОльшим
объемом данных и вводит роли и ответственности дев-опсов и ДБА на проекте.
Если у вас есть ЦОД - то это самое для вас. Кроме того PG и My могут работать
в контейнере Docker.

IB/FB как-то очень отдален от тех категорий которые я перечислил выше. Он платформо
зависим и насколько я знаю не разворачивается в докере. Это сильно ограничивает
его использование, особенно в нашу эпоху облаков.

olegbank, сомнительно.

SQLite - написан на Си. И если вы хотите распространять это приложение в составе jar то вам надо
озаботится набором дистрибутивов где SQLite будет собран отдельно под Windows/Linux.

Посмотрите в качестве примера релизы SonarQube (server) или Apache ActiveMQ.

Leonid Kudryavtsevmaytonolegbank, сомнительно.

SQLite - написан на Си. И если вы хотите распространять это приложение в составе jar то вам надо
озаботится набором дистрибутивов где SQLite будет собран отдельно под Windows/Linux.
.
Насколько я смутно помню, в Jar'нике с SQLite, которым я пользовался, вроде уже был "впихнут" SQLite и для Windows и для наиболее распространенных Linux'ов. Т.ч. лично я вроде ничем не заморачивался. Просто jar'ник, все остальное уже было сделано за меня.

Как оно работает и как внутрь Jar'а умудряются засунуть .DLL, .SO - не знаю. Я так не умею. Не разбирался.
JAR это над-множество спецификаций над zip-архивом. Так и называется JavaARchive.
В основном касается специальных текстовых файлов-дескрипторов.
И нет никаких ограничений касательно его содержания. Можно класть туда и картинки
и другие ресурсы. Другая проблема - чтобы JNI была гарантирован вызов System.loadLibrary
корректно. Впрочем я-бы не помещал платформеры внутрь такого архива.

Leonid Kudryavtsev, java приложение не требует процесса инсталляции как такового.
Обычно поставляется tar.gz архив. Вы его копируете куда вам удобно. Далее опционально
конфигурируете path,classpath,javahome... e.t.c. для системы, для профайла или вообще
для сеанса bash. Далее стартуете start.sh и все работает. native код обычно кладут на уровне
bin где-то в bin/win-32 или bin/so

Может или нет летать native.dll внутри jar я не уверен. У меня не было таких специфичных
кейсов и надо читать доку http://docs.oracle.com/javase/7/docs/technotes/guides/jni/
и разбираться.

....После копирования я имел в виду что вы его распаковываете и т.д...

GarrickmaytonИз недостатков я-бы выделил ограничения на размер (в In-memory обычно не кладут
крупные хранилища) и отсутствие внятной политики бекапов.

А кто сказал, что оно только in-memory? У Н2, например, лимит на размер базы данных 4TB, у Derby вообще нет. Есть и транзакции, и backup'ы , и репликация , и кластеризация... всё как у взрослых, только даром. Но у админов, конечно MySQL или PostgreSQL, про Oracle и DB2 вообще не говорю, пользуется большим спросом.
Мы на проекте неоднократно обсуждали заюзать H2 в качестве репозитаря для SonaqQube,
и для прочих внутренних нужд continous integration. В процессе обсуждения звучали
такие фразочки как "...аебали эти ДБА", или "сами будем админить"... e.t.c.

Но девбоксы обычно не бэкапятся так как надо. Есть какая-то базовая политика типа
раз в неделю чето-то там с пользовательских папок... А чинить упавший H2 никто из java-девелоперов
не умеет. Да и когда до дела доходит - то все стрелочкини и спрыгивают в свой уютненький Spring in Action...
В конце концов вернулись обратно в Oracle. Там ничего никогда не теряется. Archivelog
и flashrecovery включен по дефолту. Админы - суровые. Вот как-то так.

mad_nazgulmaytonМы на проекте неоднократно обсуждали заюзать H2 в качестве репозитаря для SonaqQube,
и для прочих внутренних нужд continous integration. В процессе обсуждения звучали
такие фразочки как "...аебали эти ДБА", или "сами будем админить"... e.t.c.

Насчет H2 не знаю, но PostgreSQL админится по принципу "поставил, забыл".
Только по cron'у бекапы выгружай.
Вот только в plain text, из них если что легче БД поднять.
Ну... тут надо исходит из цены той информации которая лежит. Сколько мы готовы
заплатить за сбережение последнего commit-а.

Valery Shiskinmayton,

С 1997 года в конторе, где я работал, развернул Firebird. На момент моего ухода БД содержала порядка 30 млн записей. Меня в конторе давным давно нет. БД до сих пор работает без каких-либо проблем. Где-то раз в неделю стараются сделать backup/restore и все. Никаких аминов. База переносится с сервера на сервер без проблем. Прекрасный визуальный полностью free для России manager. А про надежность, просто найдите в инете почему interbase раньше (сейчас не знаю) широко применялся в армии США. Попробуйте так поработать с Oracle, не говоря уже про цену.
Очень даже может быть. Скорее всего у вас - очень простая система. И 30 млн записей не очень
характеризуют. Скорее важно спросить какой объем этих данных горячий. И сколько конкурирующих
пишущих сессий одновременно выдерживает выша БД.

Valery Shiskinmayton,

Вообще-то термины "простая" или "сложная" скорее относятся к постановке задачи. Не знаю, как в реляционной базе можно сравнивать, что сложнее. А если уж оценивать число одновременно выполняемых транзакций, то уж точно, что Firebird по крайней мере не хуже MySql (кстати, изначально не поддерживала никаких транзакций ), Postgre или H2 (хотя Postgre - это особый случай). И вообще сравнивать СУБД без привязки к конкретной задаче - это не благодарное дело. Сразу найдутся те, кто скажет, что лучше Oracle ничего нет, другие будут уверять что MS Server - самое то и каждый будет прав.
Согласитесь в инженерном споре фраза "уж точно" звучит как-то слабо обоснованно. Как говорил
один математик за "очевидность" в тексте доказательства хочется дать в морду .

Я понимаю что не бывает единой метрики принятия решения о выгоде того или иного продукта.
Но я не просто так спросил про пишущие конкурирующие сессии. Обычно зрелость любой системы
среди DBMS оценивается как готовность поддерживать ACID при конкурирующих 10, 100, 1000 одновременных
сеансов. К слову замечу что среди NoSQL решений этот вопрос часто замыливается и выносится за скобки.

По поводу простоты/сложности. Если у вас БД с 30 млн записей. Но эти 30 млн лежат в одной таблице
то интеллектуальная ценность такой системы не очень высока. Согласитесь это тянет на курсовой проект
студента на тему (например) телеметрии или cбора сведений от "умных вещей" (internet of things).

По поводу PG, H2. Их нельзя писать через запятую. Этим фактом вы просто демонстрируете слабое знание обоих систем.
Первый вариант - от одного из отцов основателей пост-версионности. Широкий набор возможностей. Нативный код
написанный на С/C++. Вполне себе претендует на инструмент импортозамещения. Опенсорц. Можете запилить хоть свой
собственный форк. Часто PG является стандартом де-факто для базы на Linux/BSD.

H2 - это наивная попытка дать реляционный инструмент встраиваемым java-системам. Слабо-конфигурируется.
Лично для меня, как бывшего базовика, сам факт наличия или отсутствия управляющих (control) параметров говорит
очень о многом. Например о том что система - незрелая и не поддающаяся конфигурированию хотя-бы буферного кеша
блоков. Как можно пускать в продуктив систему которая не контролирует явно использование памяти? Сколько она сожрет?
Я не знаю. Я-бы никогда не пускал. Ну или там где нагрузки нет. Логины хранить. e.t.c.

Valery Shiskinmayton,

Вы уж слишком категоричны в суждениях. Насчет H2 хочу сообщить Вам, что разработчик hsqldb и H2 - один и тот же человек.
Офигеть! Как эта информация может оппонировать тому что я сказал?

Это просто забавный файт из серии что и "Волга Впадает в Каспийское море"...

Не зная ни меня ни, как я понимаю, не работав ни с Firebird ни с H2 Вы слишком уж бесцеремонно даете всему оценку.
А я тебе (выше) задавал вопрос. Сколько конкурирующих сеансов-писателей было в твоей системе?

Valery ShiskinНасчет оценки DBMS. это в теории происходит так, как Вы описали. На практике, оценивается все, начиная от сложности решаемой задачи, до толщины бумажника у владельца компании и, последнее чаще доминирует.
В практике на сравнение влияет (на мой взгляд)
1) Готовность команды разработки включиться в разработку "уже завтра".
2) Наличие поддержки каких-то сертификатов безопасности. (Так поступают обычно банки.). Для
них ни новаторство ни трендовость вообще не имеют никакого значения. Главное чтобы какой-нибудь RSA с разрядностью
не ниже чем заданный поддерживался. И чтоб вся бизнес-логика была завернута в яркие фантики наподобие Apache Felix OSGI
или Apache Karaf. Если такого сертификата нет - то можно даже не начинать. Банк скажет что эта разработка не complience
и завернет ее на этапе обсуждения.
3) Стандарты и протоколы (LDAP, SOAP, Blueprint).
4) Лицензии. Деньги.
5) Опции. Сюда как раз идут: Encryption, Olap, Partitioning, Clustering. Все что в презентациях пишут крупными буквами.