Derby还是MySQL还是。。。?

Derby还是MySQL还是。。。?,mysql,derby,Mysql,Derby,对于什么类型的需求,您会选择ApacheDerby(或JavaDB)而不是MySQL(反之亦然)?我环顾四周,人们只是比较这两个,但没有人谈论什么时候考虑每一个。我正在使用Glassfish+Java/Restlet+MySQL开发一个基于web的应用程序 我预计这个系统大约有100-200个用户,在给定的时间内大约有30-50个并发用户——大多数情况下 有人告诉我,如果我想让这个web应用程序可以下载/分发,就要看看Derby。但这是我使用它的唯一原因吗?它适合web应用程序吗?有人用过吗?你

对于什么类型的需求,您会选择ApacheDerby(或JavaDB)而不是MySQL(反之亦然)?我环顾四周,人们只是比较这两个,但没有人谈论什么时候考虑每一个。我正在使用Glassfish+Java/Restlet+MySQL开发一个基于web的应用程序

我预计这个系统大约有100-200个用户,在给定的时间内大约有30-50个并发用户——大多数情况下

有人告诉我,如果我想让这个web应用程序可以下载/分发,就要看看Derby。但这是我使用它的唯一原因吗?它适合web应用程序吗?有人用过吗?你的经历是什么?什么时候你会选择其中一个?(大多数关于比较的讨论都是在MySQL v5之前进行的,当时MySQL v5不支持存储过程、触发器等,但现在已经不是这样了)


我可以理解一个独立的DB服务器模型,其中一个web服务器发送请求,但是这个模型如何随着嵌入式DB而改变呢?还是默认在网络配置中使用Derby?

将产生影响的需求是所谓的“非功能”需求:容量、可靠性、吞吐量(和响应时间)、可用性和安全性;这与软件本身的问题有关,比如它的可用性有多容易,基于它维护软件有多困难,等等

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

MySQL是一个很好的通用选择,应用广泛。它可以配置为高可用性和可靠性(通过镜像和主从),许多程序员都很了解它,并且可以很好地集成到许多平台软件中,如Grails、Rails和JBoss

Derby很好,因为它非常独立于平台,很多人都很容易阅读Java

SQLite速度快、重量轻,或多或少是Mac上的本地产品

。。。等等

首先,找出哪些非功能需求是重要的,然后选择一个DBMS

更新

好的,继续你的评论

有了这些数字,让我先问一下,为什么要单独使用RDBMS?这是1000行-考虑简单地将它们存储在内存中,比如在序列化的集合集合中。p>
如果你真的需要一个数据库,比如说因为你使用的是Rails,那么你就不会挑战任何RDBMS——这可能很难选择,因为你所在的领域所有的选择都非常好。如果是这样,那么选择最容易使用和最容易支持的一个,这可能是但不一定是MySQL,只是因为每个人都使用它。

< P>为什么<强> DeBe< /强>和<强> MySQL < /强>您考虑的唯一RDBS?如果你说Derby,你应该检查HSQLDBH2SQLite。如果你说MySQL,你也应该看看Postgres(它有很多特性)

这只是一些免费的RDBMS的名称。当然,正如查理已经指出的那样,还有很多其他原因,也有很多理由。查看维基百科上的这个(IMO卓越)比较页面,您将发现任何RDBMS的优点和局限性:

就您的Web应用程序“可下载”的要求而言,您当然可以在Web应用程序中嵌入RDBMS(Derby、H2、HSQLDB中的任何一种)。但是你也可以让你的MySQL或者Postgres或者任何集成都可以配置,并给你的下载者关于如何设置你的webapp的说明。毕竟,当您为您的webapp使用配置了
DataSource
的容器时,这种配置很容易完成

现在,即使您认为使用嵌入式数据库开发webapp可能更容易,您也应该始终提前一步。问题如下:

  • 您是否能够直接连接到该数据库,以便轻松纠正数据不一致?(这将发生在我们所有人身上)
  • 你能很容易地改变模式吗
  • 您是否能够轻松备份数据
  • 等等等等。。。还有更多的维护问题

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

同意。这就是我想知道的——对于哪种类型的NFR,人们会选择MySQL而不是Derby(反之亦然)。Derby(或MySQL)的犹豫会迫使我为给定的场景和给定的约束做出选择吗->最多20个表,每个表最多可以增加50个条目,跨团队轻松一致,“良好”的可靠性,中等的响应时间是可以接受的(3-10秒很好:),中等的可用性(intranet app)很抱歉似乎我不清楚-数据是相关的,我有大约15个表,每个表预计最多1000行,并且会在一段时间内(每年?)单调增加。以前的数据需要作为历史记录保存。简单的序列化并不适合这个任务——它只会是关系方面和延迟加载的噩梦。我应该将我的问题重新表述为“当将Derby用于(intranet)企业应用程序时,它的局限性是什么?”而不是MySQL vs DerbyGreat!正是我想要的信息。是的,我确实看了维基百科页面,因此标题中省略了:)自从我发布了这个问题后,这些担忧确实打动了我,我们决定现在使用MySQL,并提供“一个”基于嵌入式数据库的解决方案,用于下载和评估该工具,并在需要时切换到MySQL。听起来很不错解决方案祝你好运!:-)恕我直言,我不同意这个答案。你的想法