Возникла такая пролема, делаю некую демонстрационную програму, одно из требований простота инсталяции... В связи с чем возникла проблема, кроде как бы нужно работать с БД через JDBC, но и устанавливать БД не хочется...
Нет ли какой java либы, к-ая обрабатывает простейшие SQL запросы, но на самом деле просто пишет всё в файл... скорость здесь не критична...

Слышал, что эти СУБД отличаются возможностью работать с ними без установки, т.е. работаешь с ними, как с компонентами твоей программы.
http://ru.wikipedia.org/wiki/SQLite
http://ru.wikipedia.org/wiki/Firebird Embedded

Это сообщение отредактировал(а) Platon - 18.2.2008, 17:21

И еще это поддерживают PostgreSQL и Derby, embedded mode называется.

1 мой товарищ лестно отзывался о Firebird, тока он дотНетовец, но я так полагаю с Java тоже проблем не будет.

так вроде Java DB аля Derby так позволяет работать 

Хм, афтару спасибо за вопрос, натолкнул на размышления. Оказалось, что из перечисленных Derby реализован на Java и как мне видится, и реально платформонезависимая и, как мне показалось, лучший выбор.

Добавлено через 5 минут и 47 секунд
Более того, этот прокт от Apache, говорит о многом.

Хм... Хм... Доверять просто лейблу - не есть гуд. Например, IBM - отличный широкоизвестный лейбл. А вот софт у них далёк от идеала, как корова от Бетельгейзе. Один мой друг уже намучался с их Lotus и не только.
Так что лучше всё проверять на своей шкуре.  

Хех, опередили меня аж на полчаса 

Добавлено @ 18:28
nornad, лично я тесно работаю с Apache MINA (не на производственном уровне, конечно, но факт), очень нравится, удобно, безбажно, и просто приятно, а главное быстро.

Еще у них документация хорошая (туториалы), самостоятельно разобрался, сидя только на доках сайта.

Это сообщение отредактировал(а) Platon - 18.2.2008, 18:30

Ну так я же и не говорил, что ирокезы обязательно гадость сделать должны. 
Мораль басни - доверяй, но проверяй.

С дерби похоже не все так просто, где то слышал, что для embedded достаточно приложить к проекту derby.jar и можно юзать бд как хочешь, а судя по мануалам, нужно будет запускать сервер этой дерби на определённом порту, прям как для большой СУБД... хм... а может я доку не с того конца читать стал, у самого скоро такая проблема встанет, надо будет писать курсач, нужно будет приложение работающее с БД писать, юзать для этого MS ACCESS религия не позволяет, а прикладывать к программе инсталлер какого нибудь MySQL нашим преподам пенсионерам врят ли понравится, вся надежда на дерби... и то не все так просто оказывается :(

Не волнуйся, в дерби и так, и так можно  Просто меняется строка подключения с бд.

У дерби существует (или имеется) три режима запуска (работы) - первый это встроенный или embedded, то что именно тут и нужно, а можно запустить как серверную СУБД и коннектиться к нему с любой машины на нужный порт и работать по примеру как с ораклом или любым SQL серваком, есть и третий вариант, это встроенный в J2EE или WEB сервер вот с ним еще не разобрался.

при встроенном режиме работы достаточно подключить derby.jar и работать как обычно - загрузив драйвер и создав подключение.
в режиме NetworkServer необходимо на тачке стартануть сервак (есть спец батник для этого или sh для линукса) и в своей проге загрузив драйвер NetworkClient (кажеться) законектиться на сервак.

3,14
HSQLDB - проще не придумаешь.

Добавлено через 4 минуты и 27 секунд
Hibernate использует для демонстрации примеров в своем тюториал. Там же написано как развернуть.

Взял Derby, единственный найденный минус - не поддерживается автоинкрементация Primary Key.

Почему не поддерживается? 

Создадим таблицу:


выполним вставку данных:



Это сообщение отредактировал(а) powerOn - 20.2.2008, 22:33

А вот мне интересны показатели HSQLDB, якобы показатели производительности в 2 раза лучше. Как это понимать?

А еще есть возможность и такая:



тогда инсерт может быть и таким



В первом случае произойдет вставка авто инкрементного значения, а во втором значения 100 в поле pr_key

Добавлено через 2 минуты и 41 секунду

Так тогда необходимо реальные тесты провести, кто кого под разными типами нагрузок. Но это уже надо делать компетентным людям.

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

Боюсь HSQLDB вообще не приспособлена для работы с большими объемами.

вот по этом тестировать должны (ну если захотят) знающие люди, Я вот про HSQLDB вообще не чего не знаю.

Так для больших объемов данных и СУБД соответствующие, а так для нескольких тысяч строк таблицы и не важно за 1 секунду или за 2 отработает...

Ну, я думаю, для задачи средней сложности подходит вполне.

М-да, судя по всему поосторожнее следует быть и с apache derby, и с HSQLDb. И подумать стоит ли их использовать. Столкнулся с проблемой в SQL запросах: http://forum.vingrad.ru/forum/topic-202332.html Решение, пока, таки не нашлось   

Это 

даже в Oracle работать не будет. Правило есть - если одиночный столбец попадает в извлекаемый список вместе с групповой функцией, он обязательно должен быть помещен в клаузу GROUP BY

Попробуйте, что нибудь вроде этого


Это сообщение отредактировал(а) mbasil - 26.3.2008, 16:10

mbasil, да, похоже что я поторопился. Там не сразу, но тоже нашли в чём проблема. Странно что в итоге столько времени потратилось, проблема вроде была простейшая.

Полагаю Вас ввела в заблуждение некоторая неряшливость, допускаемая разработчиками MySQL в части синтаксиса SQL. Например они допускают выполнение операции SELECT в отсутствии клаузы FROM.
А года два назад, когда немного работал MySQL столкнулся с вопиющим фактом: В таблице можно было создать ограничение NOT NULL на некоторый столбец, а потом смело внести NULL значение в этот столбец. В Oracle с такими "ляпами" я никогда не сталкивался.

Приведенная же Вами задача имеет рассмотренные ограничения, очевидно не по причине технических недоработок, а вследствие осознанного решения, что так должно работать группирование. Предполагаю, что такое поведение определено в стандарте SQL 92г., хотя гарантировать и не могу, нет времени искать текст.