哪个开源数据库是会计相关系统的最佳选择?

时间:2009-01-05 00:24:17

标签: database open-source accounting

我正处于为公司规划和设计自定义会计应用程序的早期阶段。我的目标是为数据存储部分使用开源关系数据库,我知道有两个广泛支持的实体数据库:MySQL和PostgreSQL。

对于需要事务,存储过程,函数和安全性的系统,是否有任何关于这两个数据库中哪一个最适合会计应用程序的意见,或者是否存在我缺少的另一个数据库?

我对MySQL和MS SQLServer 2005比较熟悉,但由于许可证成本问题,我试图摆脱后者。

让我补充一点:这不是像Quickbooks或Peachtree那样的会计需求。这基本上是一个处理我们提供的特定业务服务的会计的系统。可能有两到三个系统满足这种需求,在任何定制之前定价在六位数范围内,并且需要我的小公司长期与供应商结婚。因此,我们正在内部构建应用程序。

此外,虽然我很欣赏购买与构建的观点,但我还是想摆脱那个特定的宗教问题,因为购买道路已经被占用,供应商失败了。有时您只需要自己完成这项工作,而这个特定的项目和预算需要保证。

感谢大家到目前为止的回复。

13 个答案:

答案 0 :(得分:22)

有四种主要的开源关系数据库管理系统可能适合这种应用程序:Postgresql,MySQL,Firebird和Ingres。还有其他系统,例如SQLite,,但它们没有这种类型的体系结构,并且并非真正针对此类工作负载而设计。这种类型的一些其他开源数据库管理系统确实存在,但由于某些原因似乎不太可行,例如缺乏明显的供应商承诺。具有此类问题的系统示例为SAP-DB.

Postgresql具有任何开源数据库的最佳功能集,并且支持XA事务,如果您的应用程序是三层系统并且支持非平凡复杂的事务,您可能需要它。特别是如果要进行跨多个数据库调用的事务,则需要这样做。

多年来已经构建了几种PostgreSQL的商业变体,例如Illustra, GreenplumEnterpriseDB. Illustra是PostgreSQL的商业版本,随后由Informix购买。 Greenplum是一个为数据仓库应用程序设计的mofified版本。 EnterpriseDB是一家为PostgreSQL支持的商业版本提供一些增值软件的公司。

MySQL 5.x有一个功能集,支持合理的横截面功能,但它不像PostgreSQL那样功能丰富。它具有更广泛的主流接受度,并且是最容易招募熟练开发人员的开源数据库管理系统。虽然旧版本没有强大的事务支持,但InnoDB等事务性存储引擎已有一段时间了。 Sun获得的current politics surrounding生成code forks,MySQL格局为somewhat messy,,争议为quality issues in the 5.1 release.但是,MySQL是由它是最受欢迎和最知名的开源数据库管理系统,是唯一一个在开源圈之外具有重要品牌认知度的系统。

Firebird是Interbase的开源版本。最后我看,它没有XA支持,但如果您的应用程序设置为双层客户端 - 服务器系统,那就没问题了。 更新:我找不到关于此的明确规范,但文档确实表明它支持两阶段提交,但我能找到的并不具体说明它是否支持XA协议。该文档暗示JDBC驱动程序确实支持两阶段提交。

此系统的一个有趣变体是Fyracle,旨在提供与Oracle的一定程度的兼容性。这最初是作为Compiere的后端使用而开发的,它是针对Oracle构建的,与它紧密耦合。

Ingres现在可以获得开源许可证,但开源社区已经受到了一些集体打哈欠的欢迎。然而,它非常丰富且非常成熟 - 我知道人们在1990年做过INGRES应用程序,并且可以追溯到20世纪80年代。

答案 1 :(得分:16)

我的建议?别。最好买一个。对会计有更多了解的人已经写好了已经处理过GAAP的软件包。他们拥有比以往更大的用户群,可以更快地发现缺陷。这是一个经典的“购买与构建”。通过编写自己的公司,没有竞争优势。如果你这样做是因为你担心许可费用,我会说你还没有正确考虑开发时间。这是你在内部做这件事的唯一方法。

话虽如此,如果您担心SQL Server许可成本,我建议先将PostgreSQL或MySQL秒作为您选择的数据库。

答案 2 :(得分:6)

我非常同意duffymo和tuinstoel等人的回答。重新考虑您的构建与购买决策。让我告诉你一个故事:

当我在一家中型公司(国际,年收入> 1亿美元)工作时,CFO决定用Oracle Financials取代金融系统。只有该软件包与该公司使用的会计惯例不完全匹配。

因此,首席财务官聘请了一个合同程序员团队,并付钱让他们根据首选的会计实践来定制Oracle Financials。她沉没了12个月的时间,100万美元的程序员工资,再加上软件的初始成本,只是为了复制他们打算替换的会计系统。

她说,如果她不得不再做一次,她会购买商业套餐,但要将公司的会计习惯调整到软件支持的默认值。这将更容易,更快,更有可能成功。

因此,请考虑构建自定义程序包的成本。还要考虑贵公司对该软件的维护,调试和增强的持续成本。即使购买六位数的商业套餐,也可能比支付程序员开发和维护这样的系统要便宜。


为了更直接地回答您提出的问题,我认为PostgreSQL和MySQL之间没有与您的项目相关的显着差异。既然你对MySQL感到满意,你也可以选择它。

我想强制提醒您不要将FLOATDOUBLE PRECISION等不精确的数据类型用于财务数据。

答案 3 :(得分:3)

对于想要使用开源数据库的任何应用程序,请小心回答Postgres。它比MySQL更“企业就绪”,更不用说它更符合SQL标准了。 MySQL的后期版本已经有了很大的改进,但Postgres仍然在各个类别中都有所改进。

答案 4 :(得分:2)

有开源免费会计系统。像osFinancials。我真的不明白你为什么要建立自己的系统?

答案 5 :(得分:1)

对于您的应用程序,它并不重要。从sqlite到MySQL到Postgres的任何东西都可能正常工作。选择你最熟悉的那个。

答案 6 :(得分:1)

答案 7 :(得分:1)

如果您熟悉MySQL,请使用它。 但是选择适当的数据库引擎而不是默认的MyISAM

List of Storage Engines

答案 8 :(得分:1)

老实说,任何通常的嫌疑人都会做这件事。维护会计科目表和相关数据表是驱动大多数关系模型的根本问题。事实上,如果你考虑会计系统的一般期刊视图,你拥有的所有就是会计科目表和一般期刊,由交易编号,日期,描述,借方帐户和金额,信用账户和金额。你做的其他事情就是选择那些。

尽管如此,有很多完全充足,经过充分测试和接受的财务方案,包括开源免费(如啤酒)版本,除非你的意思是练习曲,研究项目,我会把我的努力投入谷歌搜索并选择一个。

看到你的更新。问题是,这个问题主要取决于非功能性需求。您打算在多个服务器上分发数据库吗?你期望多少负荷?每秒交易数或每日交易数?在过去的几年里,我已经围绕这两个系统构建了系统,而且通常是最具决定性的可靠性和可用性要求:PostgreSQL通过强制行原子性和序列化并发更新来更有效地处理单行的并发更新。另一方面,MySQL似乎更好地处理真正的大型数据库。然而第三个问题是备份 - 其中一个(我现在不记得哪一个)或多或少需要一些停机时间进行备份。

答案 9 :(得分:1)

对于内部基于Web的会计应用程序,最好将Gemstone作为免费但非开源对象数据库,将Seaside作为Web框架。否则称为GLASS。

对于内部应用程序,您将受限于开发人员的工作。 Gemstone作为一个小型图像,提供了迄今为止最好的开发人员生产力。它在更改定义时支持迁移对象允许真正的迭代开发。 Seaside通过精心设计的特定于域的语言替换模板,以构建Web应用程序。

答案 10 :(得分:1)

我在PostgreSQL上构建accounting software。它工作得很好。我会极力推荐它。事实上(无耻的插件),您可以考虑与我们合作改进我们的项目并将其作为起点。

特别有几个原因:

  1. LISTEN / NOTIFY使您能够在事情发生变化时将其他程序挂钩到您的会计数据库中,而无需经常检查表格。
  2. 我们发现大多数复杂查询的表现非常出色。
  3. Firebird和Ingres将为您提供非常坚如磐石的关系解决方案。 MySQL我不推荐,因为你真的把一切都绑定到一个只能写入db的应用程序(sql模式汤意味着关系基本上是一个私有API而不是它们在PostgreSQL,Firebird和Ingres中的公共API),以及这意味着未来的灵活性会降低。

    但是,使用PostgreSQL,您可以在一个盒子中获得一个顶级的,可扩展的开发平台。发展的步伐很高。它坚如磐石。高级功能非常有用。您不会失望。我们还没有。

答案 11 :(得分:0)

如果这是桌面应用程序,您可能需要查看SQLite。它在公共领域非常有名,而且并不十分难以使用。

答案 12 :(得分:-1)

由于您没有需要存储过程,请将其从列表中删除。

将业务逻辑放在代码中而不是数据库中会让您更开心。如果你有机会开始“干净”,那就使用数据库来获得最有意义的东西 - 持久性不处理。

一旦做出决定,MySQL和PostgreSQL之间的微妙差异就会消失。两者都是处理几乎相同的SQL的关系引擎。专注于他们最擅长的事情。

推荐:使您的应用程序独立于任何数据库特性。