Дерби или MySQL или?

Почему вы рассматриваете только Derby и MySQL? Если вы скажете Derby, вам также следует проверить HSQLDB, H2, SQLite. Если вы говорите MySQL, вам также следует проверить Postgres (который имеет гораздо больше функций).

Это просто название некоторых бесплатных СУБД. Конечно, как уже сказал Чарли, есть много других и множество причин, чтобы пойти в любом случае. Посмотрите эту (отличную IMO) страницу сравнения в Википедии, где вы найдете преимущества и ограничения любой СУБД:

http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

Что касается вашего требования о том, чтобы ваше веб-приложение было «загружаемым», конечно, вы можете встроить СУБД (любую из Derby, H2, HSQLDB) в свое веб-приложение. Но вы также можете просто настроить свою интеграцию MySQL или Postgres или любую другую интеграцию и дать своим загрузчикам инструкции о том, как самостоятельно настроить ваше веб-приложение. В конце концов, когда вы используете DataSource, сконфигурированный в контейнере для своего веб-приложения, эту настройку можно легко выполнить.

Теперь, даже если вы думаете, что вам будет проще разработать веб-приложение со встроенной базой данных, вы всегда должны думать на шаг впереди. Вопросы вроде:

• Сможете ли вы напрямую подключиться к этой базе данных, чтобы легко исправить несоответствия данных? (Это случится со всеми нами)
• Сможете ли вы легко изменить схему?
• Сможете ли вы легко сделать резервную копию ваших данных?
• и т. д. и т.п ... есть еще вопросы по обслуживанию

Поскольку ваши комментарии предполагают, что ваши данные со временем увеличиваются и должны сохраняться, я бы не стал выбирать встроенную версию, а буду хранить данные отдельно от приложения. Обратите внимание, что это не исключает Derby из дизайна вашего приложения. Это просто означает, что вам придется запускать Derby как отдельный сервер.

Требования, которые будут иметь значение, - это так называемые «нефункциональные» требования: емкость, надежность, пропускная способность (и время отклика), доступность и безопасность; это наряду с собственными проблемами программного обеспечения, например, насколько легко оно доступно, насколько сложно будет поддерживать программное обеспечение на его основе и так далее.

Oracle очень быстрый, очень надежный, очень хорошо поддерживаемый и очень дорогой.

MySQL - хороший общий выбор, широко используемый. Его можно настроить для обеспечения высокой доступности и надежности (с помощью зеркалирования и ведущего-ведомого), он хорошо понимается многими программистами и хорошо интегрируется во многие программные платформы, такие как Grails, Rails и JBoss.

Derby хорош тем, что он очень независим от платформы, и многие люди легко читают Java.

SQLite быстрый, легкий и более или менее родной для Mac.

... и так далее.

Сначала выясните, какие нефункциональные требования важны, а затем выберите СУБД.

Обновить

Хорошо, продолжаю следить за вашим комментарием.

Учитывая эти цифры, позвольте мне сначала спросить, зачем вообще нужна отдельная СУБД? Это 1000 строк - подумайте о том, чтобы просто сохранить их в памяти, скажем, в коллекции коллекций, которые вы сериализуете.

Если вам действительно нужна БД, например, из-за того, что вы используете Rails, тогда вы не оспариваете ЛЮБУЮ РСУБД - это может быть сложно выбрать, потому что вы находитесь в домене, где все доступны для выбора. совершенно хорошо. Если да, то выберите наиболее простой в использовании и поддерживаемый, которым вероятно, но не обязательно MySQL, просто потому, что все его используют.