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

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

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

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

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

17
derby mysql

2 ответов

почему и в MySQL единственный RDMBS вы считаете? Если ты скажешь , вы должны проверить HSQLDB, H2, SQLite как хорошо. Если ты скажешь в 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 со встроенной базой данных, вы всегда должны думать на один шаг вперед. Такие вопросы, как:

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

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

17

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

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

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

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

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

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

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

обновление

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

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

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

8