Firebird 用于云应用程序？
我将启动一个 POS（销售点）系统，该系统将作为常规内联网系统（处于初始测试阶段）开始，但我想稍后扩展到云产品。我将把它作为混合解决方案提供。
我希望它使用 firebird，因为部署更容易、占用空间最小并且能够使用嵌入式多线程服务器。但是，我担心firebird是否可以用于具有容错、数据复制等功能的云服务...足够可靠，足以让小公司将其业务放在上面（类似于新鲜书的服务）。
我的另一个选择是使用 Postgress，但我没有使用它的经验。
FB 是否足够好用作 SAAS 后端？有成功实施的吗？
PD：我正在考虑将其部署在 GoGrid 或 Rackspace 上......
I will start a POS (point of sale) system that will begin as a regular intranet system (in his initial-beta stage) but I want to scale later to a cloud offering. I will offer it as a hybrid solution.
I want it to use firebird, because the easier deployment, minimal footprint and the ability to use a embedded multithread server. However, I worry if firebird could be used for a cloud service with fault-tolerance, data replication, etc... to be reliable enough to small companies put his business on it (similar to the service of freshbooks).
My other option is use Postgress, but I have not experience with it.
Is FB good enough to be use as SAAS backend? Any successfully implementation?
P.D: I thinking on deploy it on GoGrid or Rackspace...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
FB 是一个很好的选择，它可以处理大型数据集，并且能够跨多个文件跨越数据库。我最近在 inmobiapp.com 上的几个网络项目中使用了它。但我认为缺少的一件事是复制，到目前为止，我使用的唯一解决方案称为 ibpreplicator，它是一个非常好的代表。工具（如果配置正确）。您可以免费试用，但必须购买许可证。
还要考虑您将使用的编程语言的驱动程序支持。上次我检查了 FB on Rails 支持不是那么好，另一方面 PHP 对 FB 有很好的支持。
FB is a great option and it can handle large data sets and has the ability to span a db across multiple files . I've been using it in a couple of web projects most recently on inmobiapp.com. But the one thing I see lacking is replication, so far the only solution I've used is called ibpreplicator it's a very good rep. tool if configured properly. You can try it for free but you have to buy a license.
Also consider driver support for the programming language you will use. Last time I checked FB on Rails support is not that good on the other hand PHP has great support for FB.
您应该在不了解 SQL 后端的情况下编写 POS 应用程序。这样你就可以随时切换后端。应用程序代码不理解持久性代码的内部结构也是有利的，否则就会出现层冲突。
执行此操作的常见方法是使用对象关系映射 (ORM) 库。 此 Firebird 常见问题解答推荐了一些适用于 Firebird 的 ORM。
You should code your POS application without any knowledge of the SQL backend. That way you can switch backends at any time. It's also advantageous that application code not understand the innards of the persistence code, otherwise you have a layer violation.
A common way to do this is to use an Object Relational Mapping (ORM) library. This Firebird FAQ recommends some ORMs that work with Firebird.
Firebird 是一个很好的 RDBMS，但不幸的是在 Web 应用程序或托管公司中传播得并不广泛。
我个人喜欢 FB 软件，但不太热衷于它周围的社区。
并使 UTF8 与区域设置不区分大小写的排序一起工作...这就是让我放弃它的原因..
我推荐 postgres、mysql（或 mariadb）。
有些人还是认为mysql不稳定，
我从来没有遇到过任何问题，但没有处理过大于 1GB 的数据。
无论您选择什么，请安排备份。
更新
有人对我的回答投了反对票。与 FB 基金会分享我的糟糕经历，确切地说，与 H. Borrie 分享我的糟糕经历并不意味着这个答案“没有用”。如果编剧的态度有所改善，我衷心祝贺FB。
Firebird is a good RDBMS but unfortunately not very wide spread in either web-applications or hosting companies.
Personally I like the FB software, but not too keen on the community around it.
And making UTF8 work with locale case-insensitive ordering... That's what made me give up on it..
I'd recommend postgres, mysql (or mariadb).
Some people still thinks mysql is unstable,
I've never had any problems, but not worked with data larger than 1GB.
Whatever you choose, schedule backups.
UPDATE
Someone downvoted my answer. Sharing my bad experiences with the FB Foundation and to be precise, with H. Borrie doesn't make this answer "not useful". If the attitude has improved from the docwriters, I sincerely congratulate FB.
对不起，我在这里听起来有点刺耳，但混合动力是胡说八道。我喜欢 SaaS POS 的想法，但不要因为走上漫长而曲折的现场软件维护支持之路而破坏了自己的乐趣。
对于客户和您来说，无需现场维护是 SaaS 解决方案最有吸引力的一个原因！
通过适当的全屏浏览器支持、简化的可用性和 SSL 加密，从一开始就使其成为纯粹的 SaaS 应用程序。还要考虑竞争对手，尤其是 Square，因为你的系统更会吸引小商家，而 Square 则遍布其中。
如果您一开始就不在现场进行操作，那么从一开始就使用合适的 Web 框架和 ORM。当您有理由和经验时，您可以稍后优化事情。
现在这只是我的观点，但是想想我刚才所说的，尤其是不要纯粹从技术角度来思考。
Excuse me sounding a little harsh here, but hybrid is bullshit. I like the idea of a SaaS POS but don't spoil the fun for yourself by going down the long and windy path of on site software maintenance support.
No on site maintenance is the single most attractive reason for a SaaS solution for both, the customer and you!
Make it a pure SaaS app from the beginning with proper full screen browser support, streamlined usability and SSL encryption. Also think about competitors especially Square, because your system will rather attract small merchants and Square is all over them.
If you don't do on site in the first place go with a proper web framework and ORM right from the start. You can optimize things later, when you have a reason and the experience to do so.
Now this is only my opinion, but think about what I just said and especially think about it not purely from a technology point of view.