Mean架构适合做ERP吗？
发布于 1个月前 作者 dabianzhixing 1007 次浏览 来自 问答

Mean架构做ERP合适吗？有没有例子？

22 回复

报表什么的有点麻烦，其他的还行吧。

1

我觉得适不适合，可以看4个东西的优点是否突出以及缺点是否可以容忍（废话）。 M:mongodb nosql的缺点 A:IE8以上，Angular的优点是IO密集 N:nodejs现在是Fork了io.js，开发时注意异步之类的。

1

这个算不算ERP…

5EE4BFF3-2CD8-49FE-9645-5D93CD8FBA2F.png

楼上这个例子就不错，有源码吗？就想找个例子学习一下

@TossShinHwa 求指点，有源码吗？

不适合，建议用关系型数据库，不然会很惨

@violet-day 为什么会很惨呢，貌似大家对MongoDB评价都不错？

@dabianzhixing MongoDB不适合做erp，不支持事务。而且mongo的数据结构设计起来容易出问题，关系型数据库只要设计符合第三范式就行，因为关系然后分表，对于你以后做查询都很方便。

@violet-day @dabianzhixing 这里有一个和上面图的结构一样的系统, 不过简单一些. 有兴趣可以看看, 源码 https://github.com/TossShinHwa/CMS 2139D8A4-5892-4420-A0EB-6594B8351F35.png

@violet-day 很多人都喜欢直接说NoSQL不支持事务, 严格的来说其实是不正确的. 因为NoSQL基本在同一个聚合上面都是具有事务性的. 你完全可以根据业务需求, 把需要事务的操作放在一个聚合里面就搞定了.

不过确实是NoSQL的查询在设计schema的时候就决定了, 所以schema的好坏会直接印象这个系统的可扩展性.

@TossShinHwa 对单个文档的操作是原子操作，但是如果文档的schema做的太复杂的，查询起来会很吃力。今年大半年就耗在个ERP上面了，心塞。

@violet-day 确实是一个坑, 被坑几次之后有经验就好了, 都是这么过来的. 因为schema直接影响查询方式, 所以一开始就一定要把所有查询的情况考虑到再做设计, 否则后面会比较坑. 一般都要多做冗余.

不过即使是需求变动, 我觉得相对于关系型数据库的数据迁移, NoSQL迁移起来要方便多了. 关系型DB数据量大了之后给table加一个column都是胆战心惊的.

@dabianzhixing @TossShinHwa 可以看看loopback这个框架，专门用来开发企业级应用，效率很高。

@violet-day @TossShinHwa 非常感谢两位大神的指导啊！这两天有别的任务，临时干了点别的，过两天有时间再细细的看看！

@violet-day loopback试过，感觉有些重，虽然集成了很多东西，但是很多你想做的它帮不了你。

@SoaringTiger 比如呢，交流下呗

既然你指定了erp,而不是其它类型, 那就明确的说不适合 nosql目前只能是辅助 erp的三个特征

  • 事务
  • 数据正确性
  • 数据实时性, 查询条件的复杂性

同nosql最初的目标都相背的

以事务为例子一张销售单需要同时变更 销售订单发货, 更新库存 更新 应收应付, 生成一或多个凭证,在凭证生成过程中更新科目 复杂的情况还有就不说了,一个文档中的事务是无法达成的 nosql的cache类设计, 冗余类设计更新通常有时效,不是及时的,导致统计数据不实时不正确, 查询条件多且复杂,导致冗余设计通常无效, 需要多个文档连接导致最终还不如关系数据库等等 但是nosql最为辅助手段 是有很多点可挖的,这个我也在摸索中,不好展开说

@violet-day 我也就试了两三天，感觉是想做成个Node里德Django，什么都得按它规定的来

@TossShinHwa 你这个不算的，最多算mis

@TossShinHwa 这种最好SQL吧，芒果会弄死你的……

@SoaringTiger 这比 Django 负责的事情更多, 指定了前段 JS 框架和后端数据库的.

@i5ting 好吧.

@hainee 确实, NoSQL 的 schema 设计需要做思维上的转变.

回到顶部