商城web项目中做到不同商品有不同的参数,数据库关联的方法:1、使用大宽表;2、表上增加一个json列;3、将共性的字段放在一个主表里;4、使用用主表 + 属性表等。使用大宽表就是用大宽表,每次需要一个新列就加,但总是nullable的。
就是用大宽表,每次需要一个新列就加,但总是nullable的。这样不同类型的记录,代码要自己记得取哪些列。好处是编码简单;坏处是,每次都要加列,做DDL很麻烦,如果是生产库,运维上会很繁琐,而且直接看表,不太容易分清楚哪个列是给哪个类型的记录预备的,必须另外单独记录文档。
表上增加一个json列(比如叫properties)每个类型数据特有的属性都塞这个json列里。在不直接支持json的db上,只能用varchar,然后业务代码自己解析这个json。如果在支持json的db上(比如mysql > 5.7.10),就稍微方便点,可以用json_extract之类的函数。此外一些ORM工具对json支持的不是很好,于是这个json到了object里就是string,需要额外处理。提一句mybatis通过挂一个type handler可以解决,还算容易。此方法的缺点是开发人员要管住json的schema,自己确保数据的合法性。
将共性的字段放在一个主表里(比如product),此外给每种类型建立一个子表(xxx_product_part)维护特有的字段。这样结构比较清晰,但是每次查询需要引入join。每次增加一种新的类型的时候也要增加对应的新表。
用主表 + 属性表。属性表就是一个大的kv(pid, key, value)。但问题是value的类型会很麻烦,毕竟可能需要字符串,整数,decimal,日期,时刻,enum等不同的类型。所以要不就是服务得自己搞这个解析转换工作,这时表就得定义为(pid, key, value_type, value_data);要不就是挨个类型定义一列,上层自己取(pid, key, value_int, value_varchar, value_decimal, …)。
每种产品直接建立新表(xxx_product, yyy_product, …),但这样做对之后的运维等工作会造成很多困难,不推荐。
如果经常增加产品的类型,可能方法2或者4会比较适合,避免每次都创建新列/新表。并且会比较灵活(但管不好就会乱套)。如果产品类型增加的不是很频繁,方法1或者3会比较适合。
设计精良的网上商城系统,包括前端、后端、数据库、负载均衡、数据库缓存、分库分表、读写分离、全文检索、消息队列等,使用SpringCloud框架,基于Java开发。
关键技术:
配置情况:
litemall = Spring Boot后端 + Vue管理员前端 + 微信小程序用户前端 + Vue用户移动端。
项目架构:
技术栈:
CRMEB打通版是历经6年时间匠心之作!系统全开源可商用,包含小程序商城、H5商城、公众号商城、PC商城、App,多种分销模式、拼团、砍价、秒杀、优惠券、抽奖、积分、会员等级、小程序直播、页面DIY,前后端分离全部100%开源。方便二开,更有详细使用文档、接口文档、数据字典、二开文档/视频教程。为开发者赋能,助力企业发展、国家富强,致力于打造较受欢迎的商城项目。
系统亮点:
运行环境:
mall项目是一套电商系统,包括前台商城系统及后台管理系统,基于SpringBoot+MyBatis实现,采用Docker容器化部署。 前台商城系统包含首页门户、商品推荐、商品搜索、商品展示、购物车、订单流程、会员中心、客户服务、帮助中心等模块。 后台管理系统包含商品管理、订单管理、会员管理、促销管理、运营管理、内容管理、统计报表、财务管理、权限管理、设置等模块。
组织结构:
mall
├── mall-common -- 工具类及通用代码
├── mall-mbg -- MyBatisGenerator生成的数据库操作代码
├── mall-security -- SpringSecurity封装公用模块
├── mall-admin -- 后台商城管理系统接口
├── mall-search -- 基于Elasticsearch的商品搜索系统
├── mall-portal -- 前台商城系统接口
└── mall-demo -- 框架搭建时的测试代码
系统架构:
延伸阅读1:商城web项目数据库存储方案
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系邮箱:hopper@cornerstone365.cn 处理,核实后本网站将在24小时内删除。