Тут в виде издевки прозвучало - "Вы еше 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