转自:https://cloud.tencent.com/developer/article/1164332 简介: 目的: 电商常用功能模块的数据库设计 常见问题的数据库解决方案 环境: MySQL5.7 图形客户端,SQLyog Linux 模块: 用户:注册.登陆 商品:浏览.管理 订单:生成.管理 仓配:库存.管理 电商实例数据库结构设计 电商项目用户模块 用户表涉及的实体 改进1:第三范式:将依赖传递的列分离出来.比如:登录名<-用户级别<-级别积分上限,级别积分下限 改进2:尽量做

数据库设计的三大范式:为了建立冗余较小.结构合理的数据库,设计数据库时必须遵循一定的规则.在关系型数据库中这种规则就称为范式.范式是符合某一种设计要求的总结.要想设计一个结构合理的关系型数据库,必须满足一定的范式. 在实际开发中最为常见的设计范式有三个:第一范式是最基本的范式.如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式:第二范式在第一范式的基础之上更进一层.第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言).也

MySQL基于左右值编码的树形数据库表结构设计   在关系型数据库中设计树形的数据结构一直是一个十分考验开发者能力的,最常用的方案有主从表方案和继承关系(parent_id)方案.主从表方案的最大缺点是树形结构的深度扩展困难,一般来说都是固定的,适合深度固定的需求.继承关系方案设计和实现自然而然,非常直观和方便.缺点当然也是非常的突出:由于直接地记录了节点之间的继承关系,因此对Tree的任何 CRUD操作都将是低效的,这主要归根于频繁的“递归”操作,递归过程不断地访问数据库,每次数据库IO都会有

对于订单来说,主要的表就是ORDER_HEADER和ORDER_ITEM.ORDER_HEADER就是所谓的订单头,一条记录代表一条订单. ORDER_PAYMENT_PREFERENCE是订单的支付,它有三个主要外键,ORDER_ID代表是哪个订单,PAYMENT_METHOD_ID代表是哪种具体付款方法,PAYMENT_METHOD_TYPE_ID代表哪种付款类型. 订单ORDER" title="ofbiz数据库表结构设计(3)- 订单ORDER"> ORDER_

ofbiz中,party的电话.地址等联系方式设计得非常巧妙,让我们来仔细分析一下. 有一个叫做CONTACT_MECH的表,这张表我们把它称作联系方式表,一个电话号码.一个通讯地址.一个电子邮件,都分别会在这张表里找到对应的一条记录.然后通过PARTY_CONTACT_MECH表与PARTY进行多对多关联,也就是一个PARTY可以对应多个联系方式,同样一个联系方式也可以对应多个PARTY(比如家庭成员共用一个电话号码). CONTACT_MECH" title="ofbiz数据库表结

ofbiz的精华就在于其数据结构(表结构)的设计.数据结构的通用性也决定了ofbiz几乎可以适用任何企业应用.我们首先来看看PARTY相关的表结构设计. 在ofbiz中,PARTY是个抽象概念,它可以是一个人(用户.员工.家人等等),也可以是个组织(公司.部门.项目组.供应商.集团客户等等).然而毕竟个人和组织的许多属性是不同的,比如姓名就只有个人有,组织只有组织名称等等,因此,在PARTY基础上派生出两个对象(两张表),PERSON带表个人,PARTY_GROUP代表组织.我们注意到在PERS

1.结构设计 1.1.    逻辑结构设计 Activiti使用到的表都是ACT_开头的. ACT_RE_*: ’RE’表示repository(存储),RepositoryService接口所操作的表.带此前缀的表包含的是静态信息,如,流程定义,流程的资源(图片,规则等). ACT_RU_*: ‘RU’表示runtime,运行时表-RuntimeService.这是运行时的表存储着流程变量,用户任务,变量,职责(job)等运行时的数据.Activiti只存储实例执行期间的运行时数据,当流程实例

[用户模块] 账户登录:邮箱/用户名/已验证手机 密码 如果将所有字段都放到一张表里存储? 数据插入异常        只想插入一个值的  由于需要主键信息,插入的一行变成新的一行,和原来的记录无关. 数据更新异常 只想更新一个值的时候 不得不更新多行   文件锁机制可能造成用户无法登录. => 可以把范围缩小到另一张表操作. 数据删除异常 只删一个值    不得不把无关的数据一起删了 核心的问题就在于   [数据冗余出错了!], 函数依赖  function(arg-1)   <- func

一.项目路由的设计 目前项目代码已经全部开源:项目地址:https://github.com/xiugangzhang/vip.github.io 视频网站前台页面路由设计 路由 请求方法 模板 作用 / GET Index.html 渲染首页 /register GET Register.html 渲染用户注册页面 /register POST Register.html 处理用户注册请求 /login GET Login.html 渲染用户登录页面 /login POST Login.htm

ecshop订单表结构ecs_order_info说明 -- 表的结构 `ecs_order_info`    CREATE TABLE IF NOT EXISTS `ecs_order_info` (  `order_id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT COMMENT '订单详细信息自增id',  `order_sn` varchar(20) NOT NULL COMMENT '订单号,唯一',  `user_id` medium

[大概流程 ]用户登录 > 选购商品 > 加入购物车 > 检查库存 >提交订单    >  选择在线支付  或 选择货到付款 > 发货 [用户模块]注册 登陆 [商品模块]前后台商品管理和浏览 [订单模块]订单及购物车的生成管理 [仓配模块]仓库库存和物流管理 [数据库实际开发模式]直接确立表名 字段 数据类型 . [数据库设计规范] Mysql5.5 早期存储引擎 Myisam 表,现代选择 Innodb(支持事务.行级锁.更好的恢复性.高并发). 统一字符集 UTF

一:动静分离 解释:最好做好静态表和动态表的分离.这里解释一下静态表和动态表的含义,静态表:存储着一些固定不变的资源,比如城市/地区名/国家(静态表一定要使用缓存).动态表:一些频繁修改的表 二:关于Null值 解释:尽量不要有null值,有null值的话,数据库在进行索引的时候查询的时间更久,从而浪费更多的时间!可以在建表的时候设置一个默认值!

真心不错的文章,可以加深对企业信息化的设计理解:) http://blog.sina.com.cn/s/blog_a2ca5d8c01017fa0.html http://blog.sina.com.cn/s/blog_a2ca5d8c01017m3r.html http://blog.sina.com.cn/s/blog_a2ca5d8c0101fbt6.html http://blog.sina.com.cn/s/blog_a2ca5d8c0101fbxt.html http://blog.

参考的优秀文章 数据库(第一范式,第二范式,第三范式) 数据库设计是件严肃.关键的事儿,一毕业,加入一个大型的行业项目,那儿的前辈资深工程师,就给我灌输数据库如何关键.神圣.深不可测的观念,所以,我一直怀着崇拜的眼神. 几年前,项目经理把一个小项目的数据库设计工作交给我,我除了花费晚上和周末去完成.后来,更由于第一次负责整个系统的数据库设计,更请教了以前公司的架构师哥们,帮我把把关,看自己有哪些木有想到的. 后来,将设计方案通过了评审,甚是高兴,毕竟自己第一次设计一个系统的表结构,尽管,是一个小

表结构设计器(EZDML)是一个免费的数据库建表的小软件,可高速的进行数据库表结构设计.建立数据模型,能迅速生成代码模板.简单界面和字典文档,支持脚本编程. 新版本号大概有下面改进: 1.修复了部分BUG. 2.导出文件支持WORD和HTML(模型图上右键导出.默认导出EXCEL.可选择文件类型为WORD和HTML): 3.支持为每一个表设置不同的背景颜色(模型图上选表右键设置实体颜色): 4.表属性的生成页支持特殊复制,可将生成结果复制为C.JAVA.DELPHI.PL/SQL等代码字符串

Java生鲜电商平台-商品分类表和商品类型表的区别与数据库设计   二者服务的对象不一样 目的也是不一样的 商品分类是为商品服务的 用来管理商品 商品类型是为扩展属性服务的 用来管理属性 举例:[转]通常我们看到的某宝.某东左侧的导航栏,它其实就是商品分类.比如女装.男装.手机等,而它下面又会有子分类,比如女装下有连衣裙.半身裙.牛仔外套等. 分类是可无限分下去的. 现在我们点击一个分类,比如笔记本,最上面的筛选条件:品牌.适用场景.显卡类型.CPU型号等,这些就是商品的属性. 商品分类起导航作

1 数据库设计 1.1 表关系梳理 仔细思考业务关系,得到如下表关系图 1.2 用户表结构 1.3 分类表结构 id=0为根节点,分类其实是树状结构 1.4 商品表结构 注意价格字段的类型为 decimal 1.5 支付信息表结构 1.6 订单表结构 乍一看,有必要搞这么多种的时间嘛?有以下诸多原因 前端显示需要,那就必须存着呀! 方便定位排查问题,比如某用户投诉某订单一直不发货,肯定就需要时间去定位 方便数据分析,比如需要计算从用户支付到最终发出商品的平均时间 根据订单状态确认相应订单时间 1

说明:Java开源生鲜电商平台中商品的spu和sku数据结构设计与架构,包括数据库图标与架构分析. 1. 先说明几个概念. 电商网站采用在商品模块,常采用spu+sku的数据结构算法,这种算法可以将商品的属性和商品的基本信息分离,分开维护,这样我们就可以在不同的类目下自定义商品信息和分类的属性信息,我们的业务系统就可以存储不同门类的商品信息了 •SPU = Standard Product Unit (标准化产品单元)SPU是商品信息聚合的最小单位,是一组可复用标准化信息的集合 •SKU=sto

Java开源生鲜电商平台-用户表的设计(源码可下载) 说明:由于该系统属于B2B平台,不设计到B2C的架构. 角色分析:买家与卖家. 由于买家与卖家所填写的资料都不一样,需要建立两站表进行维护,比如:buyer,seller. 这样进行数据库的解耦,任何一方的变动都互不影响,但是我想集中式管理,以及一些业务个性化要求,我就增加了一个users表.表结构如下: 账号唯一键,所以做了唯一键索引, 账号的准确性采用手机短信验证. 根据类型区分买家与卖家,登陆的时候,采用的就是users这种表进行维护

     最近一直在做一个电商项目,需要把原有单系统架构的项目,改造成基于服务的架构,SOA.      有点挑战,做完了,会有很大进步. 上一篇,我们描述了原有项目中的问题.  或者说是,本篇的基本背景. 本篇开始,给出我们的改进方案和技术架构.  不过,根据自己的理解,我先列出了"规范和约定".   因为,我认为"规范和约定"是具体方案和解决办法的基石,也是很多互联网项目的基本准则吧. 2.改进方案和技术架构     2.1规范和约定     2.1.1代码规范