我听说过在生产系统中使用 Firebird 数据库的两大反对意见：不支持复制，以及无法恢复备份的严重问题。但那是不久前的事了，我知道 Firebird 已经（并且仍在）不断改进和发展。
那么今天这些问题有多重要，是否还有其他破坏交易的因素会使其在生产系统中不必要地难以使用？
问问题
960 次
4 回答
1
查看 Firebird 网站上的参考资料：http ://www.firebirdsql.org/en/case-studies/
于 2012-04-19T17:50:11.137 回答
0
从 2000 年发布的第一个版本（0.9 beta）开始，我们在生产中的金融应用程序（2 层）中使用 Firebird 作为数据库服务器。
复制 - 我们使用我们自己的内部解决方案，所以我对可用的 3d 派对服务无话可说。
至于无法恢复备份的严重问题。. 我有一段时间没有遇到这些问题了。在可以备份但不能恢复的情况下，可以修改数据库结构。但是，如果不删除原始数据库，则始终可以修复数据或元数据，这使得备份/恢复例程再次为该数据库工作。
唯一要遵循的规则：还原时不要覆盖原始数据库。始终在新文件中恢复备份。
于 2012-05-04T01:02:49.390 回答
0
即使您的数据库或备份（火鸟）崩溃 - 也有团队按需进行恢复（损坏的备份或损坏的数据库）：http: //ib-aid.com/team/
于 2012-09-12T19:36:40.507 回答
0
除了我个人遇到的不可恢复的备份情况（必须对其进行测试！）和复制之外，Firebird 还缺少许多高级功能，例如：
- 列级权限
- 加密
- 跨模式连接
- 表分区
- 重做日志（“时间点恢复”）*
此外，每个表的行数和索引的宽度也有一些限制，但这不是一个固定的数字——它取决于页面和行的大小。我记得行限制通常在数十亿。
*（使用“小心写入”，Firebird 数据库文件本质上是一个事务日志和数据库文件，因此在崩溃时它应该直到最后提交的事务没有损坏。这也意味着重新启动时的恢复时间为 0。）
于 2012-05-01T18:51:08.340 回答