我正在评估MongoDB作为我们的财务/会计RESTful API的存储解决方案。我知道MongoDB缺少事务和十进制数据类型，但是：
我想我可以通过将它们存储为整数来克服缺少小数，并根据需要将它们除以/乘以精度因子。消费者将通过API层加载（GET）并保存（PUT / POST），这样我就可以在API级别处理转换。存储整数将允许根据需要进行计算和原子更新。
我没有看到MongoDB缺少事务作为显示停止，至少在我的情况下不是这样：REST API不允许大量的，一次调用它们所有的多重更新。如果在“逻辑”事务（多个后续更新调用链）中发生故障，实现回滚逻辑将是消费者的可转让性。
存储在数据库中的“对象”将是发票，库存，付款......标准会计资料。虽然关系数据模型已被证明是存储此类数据的一个很好的解决方案，但我看不出无模式存储会如何造成麻烦。拿起发票项目。我可以使用嵌套的行项目将每个文档存储在Documents集合中。当然我仍然需要几个集合：文档，付款，联系人等等，这就是为什么MongoDB对集合的使用看起来很适合我。
以前有人甚至做过类似的事情吗？我还处于设计阶段，所以我真的使用MongoDB / REST老手的一些反馈 - 谢谢。
PS：如果你想知道，我对RDBMS解决方案完全没问题，但我喜欢考虑替代方案，并且我看到了一些无模式方式的优势。首先，MongoDB输出JSON / BSON，这是REST API的工作原理。其次，无模式意味着我可以接收具有可变数量字段的文档并立即存储它，而不必担心丢失的字段（在数据库中将为空，并且在构建时将需要大量的IsNULL（fieldname）对GET请求的回应）等。答案 0 :(得分：1)
将小数存储为整数是人们正在做的事情。如果你通过MongoDB的jira中的小数支持功能请求，你会看到一些提到这是他们的解决方法： https://jira.mongodb.org/browse/SERVER-1393
请注意，当您执行map reduce和将两个或更多这样的数字相乘或相加的东西时，该因子将会复合。
至于缺乏交易，听起来好像今天对你不会有问题，但明天呢？如果你的API总是处理小单位的工作，那么肯定。也总是可以进行两阶段提交。
我认为学习新技术真是太棒了......不会暗示你不这样做。但是，当您需要查询这些字段时，请考虑无模式真的很棒。如果不这样做，那么您可以将它们全部存储在文档或关系数据库中的单个blob-up字段/列中。 （尽管每次我看到一个项目都是这样做的，他们需要3个月的时间才能开始查询/报告/关于其中一个序列化值的东西，这真的很痛苦。）