那么就用这样的关系:
商品表 属性表
商品id 属性id
商品名称 商品id
属性名称
属性值
CREATE TABLE product(pid INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
pname VARCHAR(100) NOT NULL
)
CREATE TABLE product_act(
act_id INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
pid INT NOT NULL,
act_name VARCHAR(30) NOT NULL,
act_value VARCHAR(30) NOT NULL
)
插入数据后,结果如图:
SELECT a.pname , b.act_name, b.act_valueFROM product AS a JOIN product_act AS b
ON a.pid = b.pid
商品服务作为电商平台的基础能力是电商平台使用最为频繁的基础服务之一。因此商品服务的稳定性直接关乎整个电商平台的稳健运行,在整个商品服务中商品的存储最为重要。
商品的存储技术按商品业务使用场景分别选择存储技术。常见的商品信息包含商品基本信息、商品的图片视频信息、商品的规格信息、商品的介绍信息、商品的参数信息、还有商品的销售信息等。各部分的信息结构不一样因此存储选型也会有所差异。
商品基本信息存储。商品基本信息模型固定通用性强且具有较强的事务性要求,因此一般选择关系型数据库存储,目前使用最多的就是Mysql存储。如果数据量很大需要早期规划商品的分库分表策略或读写分离策略。同时为了保护数据库会使用Redis缓存商品基本信息。
商品的图片视频存储。商品的图片和视频文件比较大,目前常见的存储方式是采用分布式对象存储数据库存储源文件。目前常用的分布式对象存储服务有阿里云OSS、AWS的S3、七牛云,还有开源分布式对象数据库FastDFS。采用关系型数据库如Mysql存储文件路径,这样就做到物理和逻辑存储分离。
商品参数信息存储。由于商品参数的不确定性通常选择MongoDB进行存储。因为MongoDB是基于JSON描述数据天然具有扩展,对于多变不确定的数据结构具有良好的扩展性。
商品介绍信息存储。商品介绍信息大多数情况下都是图文描述,一般会作为图片或静态页面进行展示。因此一般也会使用对象存储数据库存储生成的图片或静态页面。
商品的检索信息存储。商品的检索是最为频繁的 *** 作之一。目前常用的搜索引擎就是ElasticSearch。通过将商品的销售信息建立反向索引存储进ES,满足基本的搜索能力。
商品的存储数据源类型比较多,因此数据的一致性就比较复杂。目前采用最多的就是最终一致性方式。通过业务接口调用,分布式消息,还有监控binlog保持数据源间的数据更新。采取CQRS模式分别维护读写 *** 作。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)