SQLite, Java

http://stackoverflow.com/questions/41233/java-and-sqlite ?

И вдогонку, кто что думает/слышал о NestedVM? Уже в описаниях нескольких драверов ее вспоминают

Чую, что ТС хочет странного. Во-первых для жава апп sqlite не очень-то актуален, т.к. есть hsql. Во-вторых, NestedVM - какая-то атцкая хренота, судя по описанию.

NestedVM - какая-то атцкая хренота, судя по описанию.

Я тоже так подумал когда увидел насколько это некошерно. Хотя как раз цель была сделать все кошерно

Во-первых для жава апп sqlite не очень-то актуален, т.к. есть hsql.

Почему? Не спорю, просто интерестно. Как с производительностью?

Я просто почему спрашиваю, success story у sqlite потолще будет

> SQLite, Java

Странное сочетание. Java + SQLite - это как слон с маленьким писюном.

Ты не в том месте слушал эти стори :)

Не спорю, просто интерестно. Как с производительностью?

Да он (hsql) все в памяти держит. В файл лог транзакций пишет. Он аццки быстрый, но толстый. Что касается sqlite - так это поделие вообще однотредовое вроде. Можешь еще на derby посмотреть, этакий DB2 на Java.

> так это поделие вообще однотредовое вроде

не слушайте его - он даже не видел sqlite в глаза

sqlite .. поделие

Нет, я все понимаю, но хотелось бы узнать, учли ли вы при написании сообщения тот факт, что sqlite - самая распостраненная на данный момент БД (по количеству инсталляций)? Ну и качество кода там, прямо скажем, на очень и очень высоком уровне.

Ну, про «однотредовость» и говорить не о чем - учите матчасть.

Че вы хню какую-то гоните. Ну не правильно я выразился да, не однотредовое оно. Но когда я последний раз пытался заставить работать redmine на этом чуде, выяснил, что записи блокируют всю БД целиком. Гугление на этот счет дало ясный ответ - юзайте нормальную СУБД.

самая распостраненная на данный момент БД

Толсто. Это вы по инсталляциям firefox и openoffice судите? Хрен вам, системный вызов read - вот самая распространенная субд в мире!!

Вроечем, hsql - тоже поделка. Но покрайней мере она нативная для жавы, а не бинарное нечто.

Гугление дало, действительно, абсолютно верный ответ - для каждой задачи есть как оптимальные, так и неоптимальные решения, - надеюсь я тут никакой Америки не открыл? Откуда вы знаете, какую задачу решает ТС? Может быть он и не Редмайн ставит, а?

Так вот, для многих задач sqlite является оптимальным решением. И да, по количеству инсталляций sqlite и вправду обходит остальные БД. Какая разница в чем именно он используется (кстати, список не ограничивается продуктами Mozilla и OO)?

Больше инсталляций->больше багов находится->больше багов исправляется->выше качество кода

Надеюсь, с этим-то вы спорить не будете?

В любом случае, все это к вопросу vertexua никак не относится. Я, например, единственный только раз имел дело со связкой java+sqlite и использовал, кажется, sqlite4java, так что помочь по делу не могу. Прошу прощения за непреднамеренный ..ээ спор и откланиваюсь, так сказать.

Больше инсталляций->больше багов находится->больше багов исправляется->выше качество кода

А ну тут все ясно. Интерпрайз головного мозга. Медицина, так сказать, бессильна.

Мне необходима БД без сервера, просто в файле. Возможно этих файлов будет тысяча. Попробую пока hsql, потом поменять будет просто. В лучшем случае просто сменю опции подключения, в худшем перепишу DAO

Как у этих товарище с гектарными базами с горой больших блобов (альтернативная реализация моей программы)?

Вообще-то он прав.

Что-то я как-то не смачно потролил

«Так вот, для многих задач windows является оптимальным решением. И да, по количеству инсталляций windows и вправду обходит остальные ОС. Какая разница для каких задач он используется (кстати, список не ограничивается продуктами от ... )?

Больше инсталляций->больше багов находится->больше багов исправляется->выше качество кода»

Вот такой вброс помощнее будет :)

Как у этих товарище с гектарными базами с горой больших блобов

Думаецо, что плохо. Но тащить что-то бинарное в жава софт я бы не стал. Попробуй таки derby, он потяжелее но и посерьезнее будет. Если и оно будет УГ, то можно и sqlite

Кстати, я вот был свидетелем сакцесс стори по аналитической обработке около 100 млн. записей на slite. Но таки помни, что записи блокируют базу нахрен.

Если мне не изменяет память, в sqlite максимальный размер поля данных типа BLOB/TEXT - 1 Гб или что-то вроде того, и повысить/понизить его можно, пересобрав с соответствующей опцией.

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

Система будет работать на десктопах обычных юзеров, причем в фоне. Сам факт что это Java - уже чуть громоздко. Но только Java позволяет максимально элегантно, гибко и мощно решать задачу.

Это я просто обосновываю почему мне подходят только встраиваемые БД, причем еще есть причины почему мне нужно указывать конкретный файл БД

derby, hsql, h2.
когда я это дело тестировал, скорость росла, но надёжность падала именно в таком порядке, но это было несколько лет назад - с тех пор скорость-надёжность у последних двух должна была сильно вырасти

+есть ещё java-реализация sqlite, но она под dual-licensed под GPL :(

Ясно. А какие операции нужно делать с блобами? Вроде блобы можно придумать хранить как-то по-другому. Все таки преимущество sql-ных баз в простоте написания аналитических запросов, для блобов врят ли это преимущество.

В БД будут храниться дырявые файлы. Например файл с 2, 23 и 532 блоками размером с МБ, остальных блоков пока нет. Вот могу их хранить в бд, или просто в файле, а в БД хранить только метаинформацию. И еще непонятно, нужна одна БД или по БД на такой виртуальный файл. Второе - тоже вариант, так как наши БД легковесные и не используются одновременно для всех файлов. Решу что выбрать потом

Исследовал 3 бд

HSQLDB - сложно работать, нужны специфические запросы. Она без специальных запросов не уменьшается в размере вообще. После удаления всех таблиц осталось 256 МБ. Очень стремно. Тормозит на блобах

Derby - прекрасно работает, но медленно. Всегда медленно.

H2 - остановился на ней. Оно мне базу данных на 1 ГБ с блобами сгенерило за 30 сек. FileOutputStream - за 14 сек, что как бы намекает. Ждать остальных баз не хватило терпения. После drop всех таблиц БД заняла 25 кб. Приятно удивила меня БДшка.

главное потестируй как следует ситуации экстренного убивания программы - это самое слабое место H2

Это да. И я не тестировал многопоточность. У меня возможно около 100 соединений. В любом случае смогу переехать на Derby. На HSQLDB не смогу, потому что она очень нестандартная. Даже для простой работы нужны спец запросы.

Вот что пишут по H2

Whenever data is modified in the database and those changes are committed, the changes are written to the transaction log (except for in-memory objects). The changes to the main data area itself are usually written later on, to optimize disk access. If there is a power failure, the main data area is not up-to-date, but because the changes are in the transaction log, the next time the database is opened, the changes are re-applied automatically.