Дерби или MySQL или ...? - PullRequest
Новая
       25

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

17 голосов
/ 12 февраля 2011

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

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

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

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

Ответы [ 2 ]

18 голосов
/ 08 марта 2011

Почему Derby и MySQL единственная RDMBS, которую вы считаете? Если вы скажете 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 как отдельный сервер.

8 голосов
/ 12 февраля 2011

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

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

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

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

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

.... и т. д.

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

Обновите

Хорошо, следите заВаш комментарий.

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

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

...