我疯了吗？ 将已建立的产品从HSQLDB切换到Apache Derby
我有一个已建立的软件产品，它使用HSQLDB作为其内部设置数据库。 客户项目存储在此数据库中。 多年来，HSQLDB已经为我们提供了相当好的服务，但它有一些稳定性/腐败问题，我们不得不围绕代码圈子进行编码，即便如此，我们似乎也无法完全保护自己。
我正在考虑更改内部数据库。 从开发的角度来看，这样做会相当痛苦，但是向客户解释损坏的数据库（以及丢失的数据 ）并不好玩。
所以我的问题是：有没有人有足够的经验来衡量Apache Derby的长期稳定性？ 我发现谷歌的一篇post抱怨德比不稳定，但是从2006年开始，所以我觉得它在过去的4年里得到了改进。 或者，是否存在我可以使用的另一个纯Java嵌入式（进程中）数据库（商业或开源）。 表现对我来说不是很重要。 稳定是王道。 断电，良好的BLOB支持和热备份之间的数据完整性都是必须的。
请不要建议不是基于SQL的关系数据库。 我正在尝试改造现有产品，而不是从头开始，谢谢。
对于每个数据库引擎，都存在一定的损坏风险。 我是H2数据库的主要作者，我也有关于数据库损坏的报告。 测试可以减少错误的可能性，但不幸的是，几乎不可能保证某些软件“无bug”。
至于三个Java数据库HSQLDB，Apache Derby和H2，我真的不能说哪个是最稳定的。 我只能说H2。 我认为对于大多数操作来说，H2现在稳定了。 有许多测试用例专门测试数据库是否已损坏。 这包括自动测试功率损耗（使用圣诞灯计时器）。 通过电源故障测试我发现稳定性还取决于文件系统：有时我得到’CRC错误’消息意味着操作系统无法读取文件（它是Windows）。 在那种情况下，你无能为力。
对于关键任务数据，无论如何我都不会依赖于稳定的软件。 定期创建备份并对其进行测试非常重要。 某些数据库有多种方式来创建备份。 H2例如具有在线备份function，以及编写SQL脚本文件的function。 另一种方法是使用复制或群集。 H2支持简单的集群模式，我相信Derby支持复制。
我将Derby 24/7作为支持构建自动化和测试管理系统的内部数据库运行了4年。 它被全球团队使用，从未崩溃，丢失数据或损坏我的记录。 我们停止使用它的唯一原因是因为我们的公司被另一家公司收购而且更高级别的决定被宣布。 德比坚固，可靠，非常值得您考虑。
此搜索显示HSQLDB Users邮件列表中包含字符串“corrupt”的215个post。 http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.java.hsqldb.user&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.java.hsqldb.user—A
此搜索显示Derby Users邮件列表中包含相同字符串的264个post。 http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.apache.db.derby.user&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.apache.db.derby.user—A
这个显示Derby Dev邮件列表中的1003个post，其中包含相同的字符串http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.apache.db.derby.devel&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp .apache.db.derby.devel —一
查看一些post，尽管数据库开发人员付出了最大的努力，但仍然显示了数据库损坏的可能或真实情况。
HSQLDB有自己的数据库损坏问题，但多年来有所改进。 在最新版本中，已采用预防措施和修复措施来防止过去几年中报告的所有问题。
然而，新的高架存储function被certificate有一个逻辑错误，导致更新后“丢失”。 目前正在修复此问题，需要进行更广泛的测试以支持修复。
像CarlG这样的用户多年来在Derby和HSQLDB的bug修复工作中帮了很多忙。
HSQLDB项目Fred Toussi
有没有人有足够的经验来衡量Apache Derby的长期稳定性？ （……）
Derby，来自IBM Cloudscape（现在也由Sun作为JavaDB发布）是一个符合ACID标准的数据库，可以支持大量并发用户，运行嵌入式或服务器模式，并且知道可靠且生产就绪。 它没有HSQLDB那么快（Derby使用持久操作），但它很强大。 不过，你应该对它进行自己的测试。
也可以看看
- FrançoisOrsini的博客
试着看看H2 。 它是由最初创建HSQLDB但是从头开始构建的人创建的，因此不使用任何HSQLDB代码。 不确定它的稳定性与HSQL相比如何，因为我已经很久没有使用过HSQL了，而我目前只使用H2作为短期数据库。 我个人发现H2比Derby更容易上手但也许这是因为H2有一个备忘单网页。
可能可以重新编码以使用抽象层，然后运行测试以将H2和Derby与您找到的问题进行比较。
在围栏的项目管理方面，您的路线图是否会出现主要版本？ 这可能是一个相当适当的时间以这种方式消除胆量，我不会说你疯了因为它可能会消除很多难以管理的工作。 如果您希望在没有足够警告和备份的情况下对可能影响实时系统的更改进行更改，那么您可能会感到疯狂。
关于HSQLDB，它没有作为SQLite所拥有的项目的一件事是强大的测试套件的文档和苛刻的ACID合规性的在线文档。
我并不是要从HSQLDB中拿走任何东西。 它的意思是作为MySQL的替代品而不是像SQLite那样的fopen（）。 可以说HSQLDB的范围（所有Java RDBMS都是真的）更加雄心勃勃。 Fredt和他的团队用HSQLDB取得了非凡的成就。 即便如此，谷歌搜索“符合HSQLDB ACID”并不会让早期采用者感到像在阅读SQLite网站上的测试工具后所感受到的那样自信。
在http://sqlite.org/transactional.html
“SQLite是交易性的
事务数据库是指所有更改和查询都显示为Atomic，Consistent，Isolated和Durable（ACID）的数据库。 即使事务因程序崩溃，操作系统崩溃或计算机电源故障而中断，SQLite也会实现primefaces，一致，隔离和持久的可序列化事务。
我们在此重述并放大前一句话以强调：SQLite中单个事务中的所有更改要么完全发生，要么根本不发生，即使将更改写入磁盘的行为被中断也是如此
- 程序崩溃，
- 操作系统崩溃，或
- 电力故障。
在SQLite回归测试套件中，使用一个特殊的测试工具对模型对操作系统崩溃和电源故障的数据库文件的影响进行了广泛的检查。
在http://sqlite.org/testing.html
“1.0简介
SQLite的可靠性和稳健性部分通过彻底和仔细的测试来实现。
从版本3.7.14开始，SQLite库包含大约81.3 KSLOC的C代码。 （KSLOC意味着成千上万的“源代码行”，换句话说，代码行不包括空行和注释。）相比之下，该项目的测试代码和测试脚本数量是112421.1 KSLOC。
1.1执行摘要
三个独立开发的测试工具在部署配置中100％分支测试覆盖范围数百万和数百万测试用例内存外测试I / O错误测试崩溃和功耗测试Fuzz测试边界值测试禁用优化测试回归测试畸形数据库测试广泛使用assert（）和运行时检查Valgrind分析有符号整数溢出检查“
我自2009年以来一直在我的许多项目中使用Apache Derby，其中一些项目全天候运行，数百万行。
从未发生过单一的数据损坏事件。 摇滚坚固而快速。
我一直选择它作为我选择的RDBMS，除非有充分的理由不突然出现。
如果您正在寻找自包含的东西（不涉及服务器），请尝试SQLite。 这就是支持android的db api，并且非常稳定。
那么，哪一个更稳定？ 例如MySQL没有这样的问题，我害怕选择其中任何一个，但我必须。 由于Sun选择了JDK，Derby给予了更多的信任。