Derby 或 MySQL 或...？

Derby or MySQL or...?

提问by PhD

For what type of requirements would you choose Apache Derby (or Java DB) over MySQL (or vice versa)? I looked around and people just compare the two but no one talks about when to consider each one. I am developing a web-based application using Glassfish + Java/Restlet + MySQL.

对于什么类型的需求，您会选择 Apache Derby（或 Java DB）而不是 MySQL（反之亦然）？我环顾四周，人们只是比较两者，但没有人谈论何时考虑每一个。我正在使用 Glassfish + Java/Restlet + MySQL 开发基于 Web 的应用程序。

I expect around 100-200 users for this system with a load of about 30-50 concurrent users at a given time - mostly.

我预计这个系统有大约 100-200 个用户，在给定时间有大约 30-50 个并发用户的负载——大部分是。

I was told to look at Derby if I wish to make the web-app downloadable/distributable. But is that the only reason why I would use it? Is it suitable for web-apps? Has anyone used it? What has been your experience and when do you choose one over the other? (Most discussions of the comparison predate MySQL v5 when it didn't have support for stored procedures, triggers etc., But that is no longer the case).

有人告诉我，如果我想让 Web 应用程序可下载/分发，请查看 Derby。但这是我使用它的唯一原因吗？它适用于网络应用程序吗？有人用过吗？您的经验是什么？您什么时候选择其中之一？（当 MySQL v5 不支持存储过程、触发器等时，对比较的大多数讨论都早于 MySQL v5，但现在已不再如此）。

I can understand a standalone DB server model with a web-server sending the requests, but how does this model change with an embedded db? Or does one default to using Derby in the network configuration?

我可以理解带有发送请求的网络服务器的独立数据库服务器模型，但是这个模型如何随着嵌入式数据库而改变？或者在网络配置中是否默认使用 Derby？

回答by Lukas Eder

Why are Derbyand MySQLthe only RDMBS you consider? If you say Derby, you should check out HSQLDB, H2, SQLiteas well. If you say MySQL, you should check out Postgresas well (which has a lot more features).

为什么Derby和MySQL是您考虑的唯一 RDMBS？如果你说Derby，你也应该看看HSQLDB、H2、SQLite。如果你说MySQL，你也应该看看Postgres（它有更多的功能）。

This is just to name some free RDBMS. Of course, as Charlie already put it, there are lots of others and lots of reasons to go either way. Check out this (IMO excellent) comparison page on Wikipedia, where you will find benefits and limitations of any RDBMS:

这只是命名一些免费的 RDBMS。当然，正如查理已经说过的那样，无论哪种方式，还有很多其他原因和很多理由。查看维基百科上的这个（IMO 优秀）比较页面，您将在其中找到任何 RDBMS 的优点和局限性：

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

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

As far as your requirement about your webapp being "downloadable" is concerned, of course you can embed an RDBMS (any of Derby, H2, HSQLDB) in your webapp. But you can also just make your MySQL or Postgres or whatever integration configurable and give your downloaders instructions about how to set up your webapp themselves. After all, when you use a container-configured DataSourcefor your webapp, this configuration can be done easily.

就您对 Web 应用程序“可下载”的要求而言，当然您可以在 Web 应用程序中嵌入 RDBMS（Derby、H2、HSQLDB 中的任何一个）。但是您也可以让您的 MySQL 或 Postgres 或任何集成可配置，并为您的下载者提供有关如何自行设置您的 web 应用程序的说明。毕竟，当您DataSource为 web 应用程序使用容器配置时，可以轻松完成此配置。

Now, even if you think it might be easier for you to develop your webapp with an embedded database, you should always think one step ahead. Questions like:

现在，即使您认为使用嵌入式数据库开发 Web 应用程序可能更容易，您也应该始终领先一步。像这样的问题：

• Will you be able to connect to that database directly, in order correct data inconsistencies easily? (It will happen to all of us)
• Will you be able to alter the schema easily?
• Will you be able to backup your data easily?
• etc etc... there are more maintenance questions, too

• 您能否直接连接到该数据库，以便轻松纠正数据不一致之处？（它会发生在我们所有人身上）
• 您是否能够轻松更改架构？
• 您能轻松备份数据吗？
• 等等等等......还有更多的维护问题

Since your comments suggest that your data is increasing over time, and it should persist, I wouldn't choose an embedded version, but keep the data separate from the application. Note that this doesn't exclude Derby from your application design. It just means you'd have to run Derby as a standalone server.

由于您的评论表明您的数据会随着时间的推移而增加，并且应该会持续存在，因此我不会选择嵌入式版本，而是将数据与应用程序分开。请注意，这不会将 Derby 排除在您的应用程序设计之外。这只是意味着您必须将 Derby 作为独立服务器运行。

回答by Charlie Martin

The requirements that are going to make the difference are the so-called "nonfunctional" requirements: capacity, reliability, throughput (and response time), availability, and security; this along with the software's own issues, like how easily it's available, how hard it will be to maintain software based on it, and so forth.

将产生影响的需求是所谓的“非功能性”需求：容量、可靠性、吞吐量（和响应时间）、可用性和安全性；这与软件本身的问题一起，例如它的可用性有多容易，维护基于它的软件有多难，等等。

Oracle is very fast, very robust, very well supported, and very expensive.

Oracle 速度非常快，非常健壮，支持非常好，而且非常昂贵。

MySQL is a good general choice with used widely. It can be configured for high availability and reliability (through mirroring and master-slave), it's well understood by a lot of programmers, and integrates well into a lot of platform software like Grails, Rails, and JBoss.

MySQL是一个很好的通用选择，使用广泛。它可以配置为高可用性和可靠性（通过镜像和主从），它为很多程序员所熟知，并且很好地集成到了很多平台软件中，例如 Grails、Rails 和 JBoss。

Derby is good because it's very platform independent and a lot of people read Java easily.

Derby 很好，因为它非常独立于平台，而且很多人很容易阅读 Java。

SQLite is fast, lightweight, and more or less native on Macs.

SQLite 快速、轻量级，并且或多或少是 Mac 上的原生。

... and so on.

... 等等。

First, figure out what nonfunctional requirements are important, then choose a DBMS.

首先，弄清楚哪些非功能性需求是重要的，然后选择 DBMS。

Update

更新

Okay, following up your comment.

好的，关注你的评论。

With those numbers, let me ask first why a separate RDBMS at all? That's 1000 rows -- consider simply storing them in-memory, say in a collection of Collections that you serialize.

有了这些数字，让我先问一下为什么要单独的 RDBMS？那是 1000 行——考虑简单地将它们存储在内存中，比如在您序列化的集合集合中。

If you really need a DB, say because you're using Rails, then you're not challenging ANY RDBMS -- it may be hard to choose because you're in a domain where allthe choices are perfectly good. If so, then pick the one that's easiest to use and easiest to support, which is probablybut not certainly MySQL, just because everyone uses it.

如果您真的需要一个数据库，比如说因为您正在使用 Rails，那么您不会挑战任何 RDBMS —— 可能很难选择，因为您所在的领域中所有的选择都非常好。如果是这样，那么选择一个最容易使用和最容易支持的，它可能但不一定是 MySQL，因为每个人都使用它。