MongoDB非关系型数据库存储设计

1 需求分析

1.1总体需求分析

订单管理系统是物流管理系统的一部分,通过对客户下达的订单进行管理及跟踪,动态掌握订单的进展和完成情况,提升物流过程中的作业效率,从而节省运作时间和作业成本,提高物流企业的市场竞争力。

订单管理系统的主要功能是通过统一订单提供用户整合的一站式的供应链服务,订单管理以及订单跟踪管理能够使用户的物流服务得到全程的满足。订单管理系统是物流管理链条中不可或缺的部分,通过对订单的管理和分配,使仓储管理和运输管理有节的结合,稳定有效地实现物流管理中各个环节充分发挥作用,使仓储,运输,订单成为一个有机整体,满足物流系统信息化的需求。

订单管理是对商户下达的各种指令进行管理,查询,修改,打印等功能,同时将业务部门处理信息反馈到商户。订单管理系统一般包括:订单处理,订单确认,订单状态管理(包括取消,付款,发货等多种状态,以及订单出库和订单查询)等。

2 数据库设计

2.1mongodb数据库

​​​​在这里插入图片描述
本次系统采用非关系型数据库Mongodb, 与关系型数据库相比,MongoDB的优点: 不需要提前创建表:在MySQL中如果想要写入一条数据的话必须要先创建好一张表然后才能写入数据。可以任意添加或减少字段。可以处理json结构:在MongoDB可以存储一个json对象。可以使用upsert操作,即修改的数据不存在时直接插入。充分利用了计算机内存,所以查询和插入效率要远大于MySQL。我自己测试(400w随机数据)的时候只有在没有索引的情况下MongoDB的查询效率要远大于MySQL,插入效率和MySQL差不多都是8w条左右1分钟。在有索引的时候MySQL的查询要速度要高于MongoDB。

2.2系统架构图

在这里插入图片描述

2.3 模块设计

2.3.1 客户信息集合

customer_id: 客户ID
c_sex:客户性别
c_phone: 客户电话
c_name: 客户姓名
c_address: 客户地址

2.3.2产品信息集合

P_id:产品编号,
P_name: 产品名字,
P_type: 产品类型,
P_unit: 产品单位
P_pric

MongoDB数据库设计 MongoDB数据库设计全文共21页,当前为第1页。 MongoDB数据库 MongoDB is a general purpose, document-based, distributed database built for modern application developers and for the cloud era. No database is more productive to use. MongoDB is a document database, which means it stores data in JSON-like documents. We believe this is the most natural way to think about data, and is much more expressive and powerful than the traditional row/column model. MongoDB数据库设计全文共21页,当前为第2页。 Rich JSON Documents MongoDB数据库设计全文共21页,当前为第3页。 Powerful query language MongoDB数据库设计全文共21页,当前为第4页。 All the power of a relational database, and more... Full ACID transactions. 原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。一个支持事务(Transaction)的数据库,必须要具有这四种特性,否则在事务过程(Transaction processing)当中无法保证数据的正确性,交易过程极可能达不到交易方的要求。 Support for joins in queries. Two types of relationships instead of one: reference and embedded. MongoDB数据库设计全文共21页,当前为第5页。 一对多关系建模的三种基础方案 当你设计一个MongoDB数据库结构,你需要先问自己一个在使用关系型数据库时不会考虑的问题:这个关系中集合的大小是什么样的规模?你需要意识到一对很少,一对许多,一对非常多,这些细微的区别。不同的情况下你的建模也将不同。 Modeling One-to-Few One-to-Many One-to-Squillions MongoDB数据库设计全文共21页,当前为第6页。 Modeling One-to-Few 针对个人需要保存多个地址进行建模的场景下使用内嵌文档是很合适,可以在person文档中嵌入addresses数组文档 MongoDB数据库设计全文共21页,当前为第7页。 One-to-Many 以产品零件订货系统为例。每个商品有数百个可替换的零件,但是不会超过数千个。这个用例很适合使用间接引用---将零件的objectid作为数组存放在商品文档中(在这个例子中的ObjectID我使用更加易读的2字节,正常是由12个字节组成的)。 MongoDB数据库设计全文共21页,当前为第8页。 One-to-Squillions 我们用一个收集各种机器日志的例子来讨论一对非常多的问题。由于每个mongodb的文档有16M的大小限制,所以即使你是存储ObjectID也是不够的。我们可以使用很经典的处理方法"父级引用"---用一个文档存储主机,在每个日志文档中保存这个主机的ObjectID。 MongoDB数据库设计全文共21页,当前为第9页。 内嵌,子引用,父引用 三种基本的设计方案:内嵌,子引用,父引用 在选择方案时需要考虑的两个关键因素:1)一对多中的多是否需要一个单独的实体;2)这个关系中集合的规模是一对很少,很多,还是非常多。 一对很少且不需要单独访问内嵌内容的情况下可以使用内嵌多的一方。 一对很多且很多的一端内容因为各种理由需要单独存在的情况下可以通过数组的方式引用多的一方的。 一对非常多的情况下,请将一的那端引用嵌入进多的一端对象中。 MongoDB数据库设计全文共21页,当前为第10页。 双向关联Two-Way Referencing 以任务跟踪系统为例。有person和task两个集合,one-to-n的关系是从person端到task端。在需要获取person所有的task这个场景下需要在person这个对象中保存有task的id数组 在某些场景中这个应用需要显示任务的列表(例如显示一个多人协作项目中所有的任务),为了能够快速的获取某个用户负责的项目可以在task
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值