Derby или MySQL или...?

Для какого типа требований вы выбираете Apache Derby (или Java DB) через MySQL (или наоборот)? Я огляделся, и люди просто сравнили эти два, но никто не говорит о том, когда следует учитывать каждый из них. Я разрабатываю веб-приложение с использованием Glassfish + Java/Restlet + MySQL.

Я ожидаю около 100-200 пользователей для этой системы с нагрузкой около 30-50 одновременных пользователей в данный момент - в основном.

Мне сказали посмотреть Derby, если я хочу сделать загружаемое/распространяемое веб-приложение. Но разве это единственная причина, по которой я буду использовать ее? Подходит ли он для веб-приложений? Кто-нибудь использовал его? Каков был ваш опыт и когда вы выбираете друг друга? (Большинство обсуждений предшествовало сравнению MySQL v5, когда у него не было поддержки хранимых процедур, триггеров и т.д., Но это уже не так).

Я могу понять автономную модель сервера БД с веб-сервером, отправляющим запросы, но как эта модель изменяется со встроенным db? Или по умолчанию используется Derby в конфигурации сети?

Ответы

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

... и т.д.

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

Обновление

Хорошо, следуя вашему комментарию.

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

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