Посоветуйте СУБД, которую лучше всего использовать в десктопной программе на Java и которая поддерживает много даписей (500000)?

Желательно, с указанием достоинств и недостатков.

Хорош ли H2? Читал, он глючит при больших объёмах UPDATE и DELETE. Это ещё не устранили?

Можно ли использовать MS Access? Есть ли для него бесплатный JDBC?

Чем хорош/плох Personal MS SQL? Есть ли для него бесплатный JDBC?

Что лучше, Derby или H2? Или это одно и то же?

MySQL мне не очень нравится тем, что он слишком "серверный" и отдельный.

Пасиб.

Из перечисленного я б выбрал Derby , но это далеко не все варианты десктопных баз данных. Поищи темы с подобным обсуждением в разделе БД -> Общие вопросы.

Я выбрал H2, пока всё работает так как надо. Но в производственном объеме не пробовал ...  
программа для определения позиций сайта

Я бы выбрал PostgreSQL потому что умею с ним работать.
Хотя если не для erdistribute программа - то мускул. Просто лицензия у него нехорошая (

nerezus, Постгрес. Согласен.

2 nerezus
А можно чуток поподробнее про нехорошую лицензию мускула?!
Мне это просто актуально
Спасибо.

nerezus, 
skif18, человек исчет десктопную субд, что не предусматривает отдельную установку сервера СУБД, а постргес предусматривает.


alexadr, постгрес бессплатна насколько мне известно.

Для десктопной программы если пишешь на яве, подойдут такие как например hsqldb или derby (hsqldb - очень маленькая файловая дб, идеальна для простых запросов с небольшим количеством данных, derby чуть помощнее, помоему обе pure java)

Никакой мускул и постгресс!, во-первых зачем? во-вторых использовать их для десктопа - куча неудобств с их запуском, остановкой, настройкой, как использовать их в инсталлере?

дерби   

у меня в проекте используеться H2 ...  очень удобно и надеждно вообщем то

Мне вот непонятна такая формулировка. Если вы выбираете СУБД для десктоп, то непонятно что подразумевается под большими объемами. Большие объемы в моем понимаении - объемы баз данных предприятия, а что у нас в каждом доме по предприятию? Нет, я думаю, что ни у одного пользователя не будет столько информации, чтобы проверить эту недоработку.

Я тоже юзаю Постре. Простенькая и не прихотливая. Вот только 6 процессов в память запускает,
а остальным я доволен.

Мда... Сказано же для ДЕСКТОПНОГО приложения.

Вы еше Oracle предложите.

 GPL.

 Она в portable версии пашет хорошо )
+ ее можно встроить.

сам пробовал?

Тут в виде издевки прозвучало - "Вы еше Oracle предложите"

А я бы выбрал Oracle Express (XE), если есть хотя бы одна потенциальная возможность дальнейшего расширения. Уже не раз сталкивался с тем, что руководство организации говорит - "Да у нас будет что-то маленькое и исключительно десктопное". А потом оказывается, что дитятя совсем не маленькая и имеет тенденцию к росту. И наступает время, когда надо все переписывать, так как база не тянет.   Поскольку версия XE бесплатна, особых вопросов по лицензии быть не должно. А когда захочется все это портировать на сеть и множество пользователей и в части миграции на старшую версию проблем не будет. 

Выбрал бы Derby в том случае, когда известно  совершенно точно, что база всегда будет невелика, всегда будет связана исключительно с данным приложением. Например для приложения в домашнем использовании при количестве таблиц до пары десятков. Почему Derby. Да именно потому что требуется что-то малое и, например, потому, что Sun включает ее в JDK SE6, чтобы не заморачиваться на инсталляции.

Здесь по-моему все, как в артиллерии на дредноутах - одно из кардинальных положений - только самый маленький калибр и самый большой.

Это сообщение отредактировал(а) mbasil - 24.9.2008, 09:00

Ну я выходил из ситуации пересаживания на другую, более мощную СУБД, исходя из принципов самого Sun - написано раз, вроде должно работать везде.
Применительно к базам данных - пишется класс DAO, где используется только стандартный sql, одинаково работающий на всех уважающих себя СУБД (без всяких там типа новшеств, например, у Mysql ключевое слово BETWEEN И Т.Д.).
Ну если не получается и sql запросы все же разные - не беда, пишем два класса для каждой СУБД свой, а работаем с этим через интерфейсный класс, переключаясь между DAO когда это надобно, но интерфейс надо заранее предусмотреть, что собственно, я и сделал.

Тогда вся проблема съезда базы с Derby на Oracle или Mysql в переносе данных таблиц, что можно тупо сделать копированием строчек из одной таблицы в другую с помощью того же JDBC.

Ну а по теме ))))))), я бы выбрал Derby - офигительно удобно, причем в документации по ней используется именно стандартный sql, да и документация по ней ну уж очень классная - читаешь как учебник по бд.
Ну а если надо пересесть на что либо другое, так все описал чуть выше - ведь не зря jdbc придумали - единый интерфейс для всех бд, зачем же ограничивать себя )).

Проблема перехода с одной базы данных в том виде, как ее трактует  jeank, проста только до определенного размера сложности и объема. Как правило она связана с изменением структуры базы, с переносом большого количества существующих данных в другую структуру при работающей ежедневно системе и при необходимости сделать это без напряжения для пользователей (что требует руководство организации). Возникают вопросы с разными генераторами первичных ключей, созданием ограничений, обеспечивающих целостность базы данных и т.д. и т.п.

Еще не так давно я пытался все писать сам с использованием JDBC. Но сегодня это подходит только для заведомо незначительных программ, работающих с базами данных. Когда требуется управление выполнением транзакций и объектно реляционное отображение более или менее сложной схемы, сегодня разработчик не будет сам писать DAO слой - он воспользуется JP API или Hibernate, или какой либо другой ORM системой. Это облегчит переход на другую базу, но не избавит от проблем.
Например в Derby, я не могу назвать столбец year, я обязательно должен заключать его в кавычки. В MS SQL Server имеется поле типа identity, для первичных ключей в Oracle надо использовать последовательности и т.д. и т.п.

Это сообщение отредактировал(а) mbasil - 24.9.2008, 12:13

Полностью согласен, но не думаю, что речь идет о столь сложном приложении )))).
А так, как говорится - совершенству нет предела и засунуть еще и JPA, а на этом не ограничиться  - "чей то у меня двухзвенка, моловато будет хочу тиер фри", но только повторюсь, мне кажется, что речь здесь о чем то попроще - ну и решение соответствующее )))

 Нет.

SQLite?

Это сообщение отредактировал(а) gcc - 25.9.2008, 14:44