商品sku处理

  简单来说,一个电商类网站,根据平台的不同,商品的属性自然也就不同。

  一般情况来说,一个商品 goods_id 对应多个 sku_id ;

  设计表时我们会采取这样的方式:

    产品表  ---   产品sku表  ---  产品基本属性表(产品属性名称表---产品属性值表)  

    

  就目前我所接触到得项目而言:一个商品id既是一个商品的id,也是一组商品(相同属性名称,不同属性值)的主id。

  在这个项目中,我所了解到的数据库表结构基本如下:

    商品表

    goods_id  -- 商品id  goods_commondid -- 商品公共属性id  

    公共属性表

    commondid -- 公共属性id  spec_name -- 商品属性名称  spec_value -- 商品属性值

  在熟悉项目表结构的前提下,进行这样的一组操作:

    1、在点击商品详情页的时候,会进行这样的处理:

      ① 将当前 goods_id 的所有信息查询出来;

      ② 根据当前商品的 goods_commondid 从公共属性表中将商品的属性以及属性值查询出来之后进行展示;

      ③ 根据当前商品的 goods_commondid 将商品表中所有相关商品信息查询出来;

      ④ 根据公共属性表中的序列化 spec_name 以及 spce_value 进行拼接,对应到每一个具体的商品 goods_id ;

    2、根据不同的属性组合,再次调用商品详情的接口,重新加载商品信息,

  但是这里又会出现新的问题,当进行浏览记录的添加时,每次调用商品详情的接口时,如果都进行添加时,浏览记录列表展示时,相同的商品就会挨个显示,给用户的体验就比较差,后期数据库的数据可能就回因此而占用大量的空间,造成不必要的资源浪费。因此这里 初步计划采取传值方式进行处理(--- 使得相同的商品记录时记录一件商品,避免多件商品同时被记录)。

  待续。。。

  

时间: 2024-10-06 07:33:38

商品sku处理的相关文章

B2C电子商务系统研发——商品SKU分析和设计(二)

转:http://www.cnblogs.com/winstonyan/archive/2012/01/07/2315886.html 上文谈到5种商品SKU设计模式,本文将做些细化说明. 笔者研究过不少电子商务平台软件,关于SKU的设计各有不同,之所以有这样的区别,是因为面向不同规模的电子商务网站, 存在产品分类复杂度,产品数量级的差异.一种设计方式对于百货式的网站,如京东.淘宝等,也许比较方便,但也许对于一个 专卖服装的小型时尚类网站就不够方便了. 我们先看一下麦包包的 女包:http://

B2C电子商务系统研发——商品SKU分析和设计

一.SKU及相关概念定义 在设计商品SKU之前,首先让我们熟悉一下SKU和相关的一些概念. # 什么是SKU: SKU=Stock Keeping Unit(库存量单位) 同一型号的商品,或者说是同一个产品项目(商品条形码是针对企业的产品 项目来进行定义的),因为产品与产品之间有某些属性不同,用以区别开这些 不同商品的属性即商品变异属性,又称作SKU属性,因为它决定了SKU 的绝对数量. # 参考说明 百度上有一篇文章也有阐述,可以做关联阅读,我就不重复贴上了. 百度SKU参考 # 什么是SKU

工具类:每次随机生成有销售库存有实际库存的1个店铺商品和对应的2个店铺商品sku

# coding:utf-8 # @fileName :2.每次随机生成有销售库存有实际库存的1个店铺商品和对应的2个店铺商品sku.py # @createTime :2020/4/4 10:33 # @author :hongjingsheng # @email :[email protected] # @software :PyCharm # 请从下一行开始编写脚本 from testcase.goodsAPI.goodsSave.createData.create_one_goods_o

SQL行列转换——商品SKU颜色尺码合并

create procedure proc_GoodsSkuCombine as IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[GoodsTemp1]') AND type in (N'U')) DROP TABLE [dbo].GoodsTemp1 ;with roy as (select Number,ColorName,SizeName,row=row_number()over(parti

商品建模

商品建模之路 最近在做电商业务中,有关商品业务改版的一些东西,后端的架构设计采用现在很流行的微服务,有关微服务的简单概念: 微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独立部署,各个微服务之间是松耦合的.每个微服务仅关注于完成一件任务并很好地完成该任务.在所有情况下,每个任务代表着一个小的业务能力. 关于改版的业务设计,还是想尝试 DDD 领域驱动设计,之前写的一些相关文章,都是直接进行战术设计,而非在战略设计基础上进行,所以最后可能会出现一些问题,所

使用火蜘蛛采集器Firespider采集天猫商品数据并上传到微店

有很多朋友都需要把天猫的商品迁移到微店上去.可在天猫上的商品数据非常复杂,淘宝开放接口禁止向外提供数据,一般的采集器对ajax数据采集的支持又不太好. 还有现在有了火蜘蛛采集器,经过一定的配置,终于把天猫商品的数据都采集下来了(SKU信息,运费信息,库存信息,图片,商品描述等).天猫商品网页的确是很复杂,比如商品描述,还有商品描述中的图片,使用的都是懒加载,只有当用户滚动到那里了,才会去加载描述和图片.还好这些都难不倒火蜘蛛采集器.当然了,采集回来的信息也是很复杂的,需要我们清楚了解淘宝的商品数

POST /product/:id 获取单个商品

{         itemid: "272475230",         item_name: "又再又环北冰洋",         stock: 11,         price: "11111.00",         sold: 0,         seller_id: "406467",         istop: 0,         merchant_code: "2e",      

YY淘宝商品数据库设计

http://www.cnblogs.com/mmmjiang13/archive/2010/11/04/1868609.html 前言 这几个月都在做一个通过淘宝API线下管理淘宝店的系统,学习了很多东西,这里想对淘宝商品表设计用自己的想法表现出来,如果你觉得很扯淡,可以写下自己的看法.OK,切入正题. 淘宝的商品这块的复杂程度,是我见过的电子商务网站中最复杂的,灵活性最高的.在看下文之前,先说一下在淘宝中的以下名词:关键属性,销售属性,非关键属性.如下图: 关键属性:能够确认唯一产品的属性,

谈谈我对sku的理解(2)----数据库设计

接着说一下,我们设计这个商品sku发布功能时候的表设计 一. 属性和属性值首先,我们定义了最最基础的信息表 属性表,和属性值表.比如 我现在需要一个16g的iphone, 那么16g就是一个属性值,它对应的属性就是内存,可以这么理解.在这里我们没有引入像淘宝京东先分品牌的概念,而是把所有的这些信息,当做是一种属性来处理.在表中可以看到,每个属性值需要关联属性表的主键. 属性表:    属性值表: 二.商品信息表接着是我们的商品主表 这里我们的商品根据,根据需要列举这些列,可以注意到这里面并没有任