CN104516895B - 商品对象库存信息处理方法及系统 - Google Patents
商品对象库存信息处理方法及系统 Download PDFInfo
- Publication number
- CN104516895B CN104516895B CN201310452911.3A CN201310452911A CN104516895B CN 104516895 B CN104516895 B CN 104516895B CN 201310452911 A CN201310452911 A CN 201310452911A CN 104516895 B CN104516895 B CN 104516895B
- Authority
- CN
- China
- Prior art keywords
- sku
- inventory
- information
- request
- merchandise items
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2322—Optimistic concurrency control using timestamps
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请公开了商品对象库存信息处理方法及系统,其中,所述方法包括:接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在最小销售属性sku维度上共享的库存数量以及指定共享的至少两个sku;根据该商品对象的标识信息定位到该商品对象的库存信息;从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;通过以下方式对该商品对象的库存信息进行更新存储:以一个主sku对应一条库存记录的方式,对该商品对象需要在所述sku维度上共享的库存数量进行存储。通过本申请,能够在支持在指定维度上的库存共享的同时保证库存数量的准确性。
Description
技术领域
本申请涉及库存信息处理技术领域,特别是涉及商品对象库存信息处理方法及系统。
背景技术
在电子商务交易平台中,第一用户可以将交易对象(例如,商品、服务等)的信息(包括各种描述信息等),发布到交易平台中。并且还可以根据其可销售对象的数量、在线销售计划等,设置对象的库存数量。一方面,第二用户在交易平台中可以查看到每个对象的库存数量,并以此来决定是否需要马上购买;另一方面,在系统内部,还需要根据第一用户的设置、第二用户的购买行为等,对对象的库存数量进行更新,以显示出对象的最新库存数量,第一用户可以根据最新的库存数量决定是否追加库存,或者指定后续的销售计划,等等。
现有技术在保存商品对象的库存信息时,一般是以一个商品对象对应一条记录的方式进行存储。也就是说,第一用户针对某商品对象设置的库存信息,全部被压缩到一条记录中进行存储。但是,同一个商品对象一般可能包含多个sku(最小销售属性,例如,对于手机商品而言,有白色sku、黑色sku等),每个sku下可能具有不同的库存数量,需要分别设置,另外商品对象在每个时间点的库存数量也可能需要分别设置,例如,假设某商品对象是酒店的某房型,由于房型的数量是固定的,第二用户在购买时也一般会指定购买某一天或者某几天的房间,因此,需要分别设置每一天的库存数量,等等。如果按照现有技术中的存储方式,则需要对各个sku设置不同的id,将各个sku分别在多个时间点/时间段上的库存以JSON(JavaScript Object Notation,它是一种轻量级的数据交换格式)的方式压缩到一行记录存储。例如,(skuid1,day1,数量1;skuid1,day2,数量2;skuid2,day1,数量3;skuid2,day2,数量4……)。
现有技术中的这种实现方式至少存在以下问题:
在有些场景下,同一份库存数量可能需要在时间维度和/或sku维度上共享。例如,某公园门票,第一用户指定在7月1日至7月4日一共可以销售100张,也就是说,如果7月1日售出20张,那么7月2日至7月4日就只能销售80张,7月1日至7月4日这一时间段共享这100张库存。又如,某海滩酒店的商品对象:大床房,大床房搭配不同的服务构成不同的sku:大床房含早餐(sku1)、大床房接机(sku2)、大床房不含早餐(sku3),本质上房源都是大床房,数量一致,搭配不同的服务销售不同价格,故该商品大床房下的sku之间库存应该设置为共享关系,等等。如果按照现有技术中一个商品对象对应一条记录的方式,则无法或者很难做到sku间的库存共享、时间维度的库存共享、sku+时间维度的库存共享的同时保证库存数量的准确性。
发明内容
本申请提供了商品对象库存信息处理方法及系统,能够在支持库存共享的同时保证库存数量的准确性。
本申请提供了如下方案:
一种商品对象库存信息处理方法,包括:
接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在最小销售属性sku维度上共享的库存数量以及指定共享的至少两个sku;
根据该商品对象的标识信息定位到该商品对象的库存信息;
从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
通过以下方式对该商品对象的库存信息进行更新存储:
以一个主sku对应一条库存记录的方式,对该商品对象需要在所述sku维度上共享的库存数量进行存储。
一种商品对象库存信息处理方法,包括:
接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在时间与最小销售属性sku两个维度上共享的库存数量以及指定共享的开始时间、结束时间及至少两个sku;
根据该商品对象的标识信息定位到该商品对象的库存信息;
从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
通过以下方式对该商品对象的库存信息进行更新存储:以主sku加时间段信息对应一条库存记录的方式,对该商品对象需要在时间与sku两个维度上共享的库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
一种商品对象库存信息处理方法,包括:
接收第一用户为同一商品对象设置库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、不需要共享的库存数量和/或需要在指定维度上共享的库存数量,所述指定维度包括时间维度、最小销售属性sku维度中的一种或多种组合;
根据该商品对象的标识信息定位到该商品对象的库存信息,并根据所述第一请求中携带的库存数量,对该商品对象的库存信息进行更新存储,其中:
对于不需要共享的库存数量,以该商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存数量进行存储;
对于需要在时间维度上共享的库存数量,以一个时间段信息对应一条第二库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间;
对于需要在sku维度上共享的库存数量,从指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并以主sku对应一条第三库存记录的方式,对库存数量进行存储;
和/或,
对于需要在sku维度以及时间维度上共享的库存数量,指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,以主sku加时间段信息对应一条第四库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
一种商品对象库存信息处理系统,包括:
第一请求接收单元,用于接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在最小销售属性sku维度上共享的库存数量以及指定共享的至少两个sku;
库存信息定位单元,用于根据该商品对象的标识信息定位到该商品对象的库存信息;
关联关系记录单元,用于从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
第一存储单元,用于通过以下方式对该商品对象的库存信息进行更新存储:以一个主sku对应一条库存记录的方式,对该商品对象需要在所述sku维度上共享的库存数量进行存储。
一种商品对象库存信息处理系统,包括:
第一请求接收单元,用于接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在时间与最小销售属性sku两个维度上共享的库存数量以及指定共享的开始时间、结束时间及至少两个sku;
库存信息定位单元,用于根据该商品对象的标识信息定位到该商品对象的库存信息;
关联关系记录单元,用于从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
第二存储单元,用于通过以下方式对该商品对象的库存信息进行更新存储:以主sku加时间段信息对应一条库存记录的方式,对该商品对象需要在时间与sku两个维度上共享的库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
一种商品对象库存信息处理系统,包括:
第一请求接收单元,用于接收第一用户为同一商品对象设置库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、不需要共享的库存数量和/或需要在指定维度上共享的库存数量,所述指定维度包括时间维度、最小销售属性sku维度中的一种或多种组合;
定位及存储单元,用于根据该商品对象的标识信息定位到该商品对象的库存信息,并根据所述第一请求中携带的库存数量,对该商品对象的库存信息进行更新存储;
其中,所述定位存储单元包括:
第一库存记录存储子单元,用于对于不需要共享的库存数量,以该商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存数量进行存储;
第二库存记录存储单元,用于对于需要在时间维度上共享的库存数量,以一个时间段信息对应一条第二库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间;
第三库存记录存储单元,用于对于需要在sku维度上共享的库存数量,从指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并以主sku对应一条第三库存记录的方式,对库存数量进行存储;
和/或,
第四库存记录存储单元,用于对于需要在sku维度以及时间维度上共享的库存数量,指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,以主sku加时间段信息对应一条第四库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
根据本申请提供的具体实施例,本申请公开了以下技术效果:
通过本申请实施例,如果需要在sku维度上实现库存数量的共享,则可以确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并仅记录主sku与共享的库存数量之间的对应关系,子sku不再出现在库存记录中。这样,后续在对存在sku维度的共享关系的库存记录进行修改的过程中,可以通过查询主sku与子sku之间的关联关系,将用户发起的对子sku的库存记录进行修改的请求,转换为对主sku的库存记录进行修改,从而能够保证库存数量的准确性。
另外,对于同一商品对象包含多种类型的库存信息的情况下,可以生成多条库存记录,其中,对于不需要进行共享的库存信息,可以以商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存信息进行存储,这样,在对某一sku的某一时间点中的库存信息进行访问时,可以仅取出这条库存记录,其他的库存记录不受影响,因此有利于提高系统性能,同时也方便在时间或者sku上进行关联。其中,如果需要在时间维度上共享库存信息,则可以以商品对象的指定时间段对应一条库存记录的方式,对库存信息进行存储,并在库存记录中记录共享的开始时间以及结束时间;对于需要在sku维度上共享的库存信息,确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并在第三库存记录中记录主sku与共享的库存数量之间的对应关系;如果同时还需要在时间维度上共享,则还在所述第三库存记录中记录共享的开始时间以及结束时间。最终接收到访问指定商品对象的库存记录的请求时,就可以根据请求中指定的时间和/或sku信息,读取对应的库存记录,并按照请求进行处理。因此,在存在时间和/或sku维度上共享库存信息的情况下,在对库存记录进行修改、查询等过程中,能够保证库存数量的准确性。
当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的第一方法的流程图;
图2是本申请实施例中业务模型及对应的判断语句示意图;
图3是本申请实施例提供的第二方法的流程图;
图4是本申请实施例提供的第三方法的流程图;
图5是本申请实施例提供的第一系统的示意图;
图6是本申请实施例提供的第二系统的示意图;
图7是本申请实施例提供的第三系统的示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本申请保护的范围。
在本申请实施例中,对于同一商品对象而言,例如某手机、某酒店的某房型等等,在存储库存信息时,并不是按照一个商品对象对应一条库存信息的方式进行存储,而是将一个商品对象的库存记录按照sku+时间的方式进行展开,在不需要共享的情况下,一个skuid+一个时间点就可以对应一条库存记录,这样,如果某商品对象存在3种不同的sku,并且为10个时间点设置了库存信息,则该商品对象总共对应30条库存记录。如果需要对某个时间点或者某个sku的库存信息进行修改(例如,第一用户进行追加或者第一用户产生交易行为之后进行扣减等等),则可以单独取出该时间点或者该sku对应的库存记录进行锁定,其他的库存记录则不会处于锁定状态,可以提供给其他的应用来访问,因此,在对库存记录进行高并发的访问请求的情况下,提高效率,保证操作的成功率。
另外,更为重要的是,这种拆分为多条库存记录的方式,也为在sku和/或时间维度上存在库存信息共享的情况带来了方便,例如,对于需要在某几个sku上共享的库存信息,则可以设置其中一个sku为主sku,其他sku为子sku,并在系统中保存主sku与子sku之间的关联关系,同时,仅存储主sku对应的库存信息,当需要对主sku或者与其关联的子sku的库存信息进行修改时,最终都是对该主sku的库存信息进行修改。如果是需要在某时间段内进行共享,则可以将这段时间内的库存记录合并为一条,在该条库存记录中记录下共享的开始时间以及结束时间,在需要对某时间点对库存记录信息修改时,就可以判断该时间点是否落在该开始时间以及结束时间的范围内,如果是,则对这种包含共享时间段信息的库存记录进行修改,从而保证存在共享情况下,库存记录的正确性。下面对此进行详细地介绍。
首先需要说明的是,在实际应用中,用户在对某商品对象的库存信息进行设置时,往往会针对同一商品对象设置多种不同类型的库存信息,因此,最终在生成该商品对象的库存记录时,也可以分成多种类型的库存记录进行存储,每一种类型下又可能包括多条库存记录。例如,某商品对象需要在某时间段内共享某些库存,还有一些库存需要在某几个sku之间共享,其他的库存则不需要共享;此时,在存储该商品对象的库存信息时,就可以存在三种类型的库存记录,一种是需要在时间维度上共享的库存记录,一种是需要在sku维度上共享的库存记录,还有一种是不需要共享的库存记录,其中的第三种库存记录一般是由多条库存记录组成的,因为如果不需要共享,则会以一个sku+一个时间点对应一条库存记录的形式来保存。为了便于对各种类型的库存记录都进行介绍,下面首先在实施例一中,对为同一商品对象设置多种类型库存信息的情况为例,对本申请实施例提供的方案进行详细地介绍。
实施例一
参见图1,本申请实施例首先提供了一种商品对象库存信息处理方法,该方法可以包括以下步骤:
S101:接收第一用户为同一商品对象设置库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、不需要共享的库存数量以及需要在指定维度上共享的库存数量,所述指定维度包括时间维度、最小销售属性sku维度中的一种或多种组合;
具体实现时,设置库存信息的第一请求一般是由用户发起的。需要说明的是,由于设置库存信息的用户与最终对库存信息发起访问请求(包括查询、扣减等)的用户往往是不同的,为了便于区分,这里将发起设置库存信息请求的用户称为“第一用户”,将发起访问库存信息请求的用户称为“第二用户”。例如,在电子商务交易平台中,第一用户往往是卖家用户,而第二用户往往是第二用户,等等。另外需要说明的是,本申请实施例中的第一请求包括第一用户在首次为某商品对象设置库存信息时的请求,例如针对新上线的商品对象,设置其库存信息等。另外,第一请求也包括第一用户对某商品对象的库存信息进行修改的请求,例如第一用户之前为某商品对象设置过库存信息,但是基于在线销售计划的改变,或者新货源的补充等,可能需要对商品对象的库存信息进行修改。在本申请实施例中,将上述两种情况统一称为是第一用户发起的为商品对象设置库存信息的请求。
具体实现时,可以为第一用户提供库存信息设置页面,第一用户登录到系统中之后,进入该设置页面,并在页面中设置库存信息。由于库存信息一般都与时间相关,因此,在该设置页面中可以为第一用户提供一日历控件,第一用户可以在该日历控件中选择需要设置库存信息的日期,并为各个日期设置具体的库存数量等信息。同时,设置页面中也可以保存为各个不同的sku设置库存信息的入口,用户可以先指定某sku,然后在日历控件中,为该sku在各个日期上的库存数量进行设置。当然,在日历控件中,用户可以为各个日期分别设置不同的库存数量,如果每个日期对应的库存数量都相同,则还可以进行批量设置,等等。如果需要在某时间段内或者在某几个sku上进行库存信息的共享,则也可以从相应的入口进行设置,例如,用户可以添加共享时间段的开始时间以及结束时间,可以指定需要共享的sku,并将其中一个指定为主sku,等等。
如前文所述,在为同一商品对象设置库存信息中,允许设置多种不同类型的库存信息。例如,在对某商品对象从7月1日到7月10日的库存信息进行设置时,可能是设置为从7月1日到7月5日共享某库存数量A,从7月6日到7月10日,每天的库存数量均为数量B。或者,对于某商品对象,存在三种sku,其中的skuid1和skuid2需要共享库存数量C,skuid3的库存为数量D,等等。总之,第一用户提交了设置库存信息的请求后,可以从中判断出是否存在需要在时间和/或最小销售属性sku维度上共享的库存信息。
S102:根据该商品对象的标识信息定位到该商品对象的库存信息,并根据所述第一请求中携带的库存数量,对该商品对象的库存信息进行更新存储;
在收到第一用户的第一请求之后,首先可以根据该商品对象的标识信息定位到该商品对象的库存信息,然后可以并根据第一请求中携带的库存数量,对该商品对象的库存信息进行更新存储。当然,如果是首次为某商品对象设置库存信息,则在根据该商品对象的标识信息定位到的库存信息可能为空,此时,可以新建该商品对象的库存信息,相当于是从无到有的更新存储过程。具体在进行存储时,针对不同的库存记录类型,可以包括以下S103至S106五个步骤。当然,这五个步骤之间并没有严格的顺序关系,具体在进行存储时,各种类型的库存记录可以按照任意的顺序进行存储,还可以并行存储等等。
S103:对于不需要共享的库存数量,以该商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存数量进行存储;
如果某库存数量不需要共享,则就可以以一个skuid+一个时间点对应一条库存记录的方式,对库存信息进行存储。例如,对于某商品对象,指定其skuid1在7月1日的库存数量为100件,7月2日的库存数量为100件,skuid2在7月1日的库存数量为50件,7月2日的库存数量为50件,skuid1与skuid2的库存之间相互独立;则可以生成四条库存记录:
skuid1 7月1日 库存为100件
skuid1 7月2日 库存为100件
skuid2 7月1日 库存为50件
skuid2 7月2日 库存为50件
这样,如果接收到了对某sku在某天的库存记录进行访问的请求,就可以单独取出该条库存记录进行处理,其他的库存记录不受影响。例如,某第二用户购买了7月1日的skuid1对应的商品,系统会接收到需要对skuid1在7月1日的库存进行扣减的请求,此时,就可以仅将其中的第一条记录取出并锁住,对库存数量进行扣减之后,再进行解锁。但在第一条记录被锁住的这段时间,其他记录并不会被锁住,仍然可以供其他业务对象来访问。也就是说,如果业务对象1需要修改第一条库存记录,业务对象2需要修改第二条库存记录,并且业务对象1与业务对象2的请求是同时发出的,则可以将修改这两条库存记录的操作进行并行处理,不需要等到其中一个请求处理完成之后再处理另一个请求,因此,效率得到提高。
S104:对于需要在时间维度上共享的库存数量,以一个时间段信息对应一条第二库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间;
如果第一用户发起的生成库存记录的请求中,存在需要在时间维度上共享的库存信息,则可以使指定的时间段对应同一条库存记录,在该库存记录中记录下共享的开始时间、结束时间,以及在这段时间内的库存数量等信息。例如,某用户指定某商品对象在7月1日至7月5日共享100件库存,则对应的库存记录可以为:
skuid 7月1日至7月5日 库存为100件
当然,在实际应用中,一条库存记录中还可以存在其他字段,例如,在一种实现情况下,库存记录包含的字段以及各自的含义可以如表1所示:
表1
也就是说,对于不需要在时间维度上共享的库存信息,也可以根据表1中的各个字段生成库存记录,只不过将其中的开始时间与结束时间设置为相同的值即可,例如,某sku下7月6日的库存,则可以设置为startDate:7月6日,endDate:7月6日。
如前文所述,在对同一商品对象设置库存信息时,可以既存在需要共享的库存信息,也存在不需要共享的库存信息,则对于该商品对象而言,可以存在多种不同类型的库存记录。例如,在对某商品对象从7月1日到7月10日的库存信息进行设置时,可能是设置为从7月1日到7月5日共享某库存数量A,从7月6日到7月10日,每天的库存数量均为数量B。则共可以生成6条库存记录,其中一条为7月1日到7月5日的包含有共享信息的库存记录,剩余五条为不存在共享信息的库存记录。
这样,在接收到访问指定商品对象的库存记录的请求时,如果请求中指定的时间落在库存记录中记录的开始时间以及结束时间范围内,则就可以读取这条库存记录,并按照具体的请求,对这条库存记录中的库存信息进行处理。例如,假设某条库存记录为:
Skuid1 startDate:7月1日 endDate:7月5日 库存为100件
如果接收到的访问请求中,指定的时间点是7月3日,则发现该时间点刚好落在7月1日至7月5日之间,因此,就可以将上面这条库存记录取出,进行后续的修改或者返回查询结果。
对于同一个sku而言,可能存在多条库存记录。例如,对于skuId1,除了在7月1日至月5日内共享100件库存之外,在7月6日至7月10日之间每天还分别存在50件库存,则该sku存在6条库存记录。如果接收到的访问请求中,指定的时间点是7月8日,则可以将该skuId在7月8日对应的库存记录取出,进行后续的处理或者返回查询结果。
S105:对于需要在sku维度上共享的库存数量,从指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并以主sku对应一条第三库存记录的方式,对库存数量进行存储;
如果需要在某几个sku上共享某一份库存,则用户在设置库存信息时,可以将其中一个sku指定为主sku,其他的sku则自动成为子sku,并生成主sku与子sku之间的关联关系,进行存储,同时,记录主sku与共享的库存数量之间的对应关系,子sku不再单独生成库存记录。其中,主sku与子sku之间的关联关系可以通过表2的形式来存储。
表2
字段 | 类型 | 描述 | 备注 | 是否可空 | 主键 |
id | long | 主键 | N | Y | |
itemId | long | 主商品对象Id | N | N | |
skuId | long | 主skuId | N | N | |
userId | |||||
subItemId | long | 子商品对象Id | N | N | |
subSkuId | long | 子skuId | N | N | |
subUserId | |||||
status | int | 库存状态 | 0.删除1.有效 | N | N |
gmtCreate | |||||
gmtModify |
例如,某商品对象存在三个sku,分别为skuId1、skuId2、skuId3,需要在其中的skuId1、skuId2之间共享100件库存,并将其中的skuId1指定为主sku;skuId3具有80件库存。则这100件库存就是需要在sku维度上共享的库存,因此,就可以生成主sku与子sku的关联关系表,主sku为skuId1,子sku为skuId2。并且在库存记录中记录下主sku的标识以及共享的库存数量,例如:
skuId1 100件
这样,在需要访问skuId2的库存信息时,首先可以判断各条库存记录中是否存在该skuId2对应的库存记录,如果不存在,则判断该skuId2是否存在某主sku与子sku关联关系表中,如果存在,根据其中的主skuId,找到主sku对应的库存记录,并取出该条库存记录进行后续的处理即可。
S106:对于需要在sku维度以及时间维度上共享的库存数量,指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,以主sku加时间段信息对应一条第四库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
在实际应用中,可能需要同时在时间与sku两个维度上进行共享的情况。此时,同样可以生成主sku与子sku的关联关系表,并在记录主sku对应的库存记录时,同时在库存记录中记录下共享时间段的开始时间以及结束时间。例如,某商品对象存在三个sku,分别为skuId1、skuId2、skuId3,需要在其中的skuId1、skuId2之间、在7月1日至月5日内共享100件库存,并将其中的skuId1指定为主sku;skuId3具有80件库存。则这100件库存就是在时间以及sku维度上都需要共享的库存,因此,就可以生成主sku与子sku的关联关系表,主sku为skuId1,子sku为skuId2。同时,在库存记录中记录下主sku的标识、共享时间段的开始时间、结束时间以及共享的库存数量,例如:
skuId1 startDate:7月1日 endDate:7月5日 100件
这样,在需要访问skuId2在7月3日的库存信息时,首先可以判断各条库存记录中是否存在该skuId2对应的库存记录,发现不存在,则判断该skuId2是否存在某主sku与子sku关联关系表中,发现存在,根据其中的主skuId,找到主sku对应的库存记录,并且发现请求访问的时间点7月3日刚才落在7月1日与7月5日之间,因此,就可以取出这条库存记录进行后续的处理。
当然,对于同一个主sku而言,也可能存在多条库存记录。例如,对于主skuId1,除了在7月1日至月5日内共享100件库存之外,在7月6日至7月10日之间每天还分别存在50件库存,则该主sku存在6条库存记录。这样,假设需要访问的是skuId2在7月8日的库存信息时,首先可以判断各条库存记录中是否存在该skuId2对应的库存记录,发现不存在,则判断该skuId2是否存在某主sku与子sku关联关系表中,发现存在,则根据其中的主skuId,找到主sku对应的库存记录,并且发现请求访问的时间点7月8日并未落在7月1日与7月5日之间,因此,就可以取出该skuId1对应的7月8日的库存记录进行后续的处理。
按照上述方式对商品对象的库存信息保存为多种类型下的多条库存记录之后,第二用户在发起访问库存记录的第二请求时,就可以仅将与第二请求匹配的库存记录锁定,不会影响到对该商品对象的其他库存记录的访问。也就是说,接收到第二用户访问该商品对象的库存数量的第二请求时,根可以据第二请求中指定的时间和/或sku信息,读取与第二请求中指定的时间和/或sku信息相匹配的库存记录,并按照第二请求中的指令对相匹配的库存记录进行处理。
其中,如果第二请求中指定的时间落在某第二库存记录/第四库存记录(因为第二库存记录与第四库存记录中都包括时间段信息)中记录的开始时间以及结束时间范围内,则读取该第二库存记录/第四库存记录,并按照第二请求中的指令对该第二库存记录/第四库存记录中的库存信息进行处理。
如果不存在与所述指定的sku信息匹配的库存记录,且指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的第三库存记录/第四库存记录,并按照第二请求中的指令,对该第三库存记录/第四库存记录中的库存信息进行处理。
如果不存在与第二请求中指定的sku信息匹配的库存记录,但指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的第四库存记录,如果第二请求中指定的时间信息落在该第四库存记录中开始时间以及结束时间范围内,则按照第二请求中的指令对该第四库存记录中的库存信息进行处理。
需要说明的是,本申请实施例中所谓的第二用户发起的对库存记录的第二请求,可以包括对库存记录进行修改的请求,例如,第二用户指定某交易行为后,对对应的库存记录中的库存数量进行扣减,等等。另外,除了修改请求之外,还可以包括对库存记录进行查询的请求,例如第二用户在访问某商品对象的详情页面时,需要查询该商品对象的库存数量,等等。但无论是修改请求还是查询请求,请求中都会携带有具体的skuId和/或时间信息,进而就可以根据这些信息从各条库存记录中定位到相匹配的进行读取,并进行修改,或者返回查询结果。
需要说明的是,对于查询库存记录这种访问请求而言,可能存在查询某一skuID在某一指定时间段内的库存记录的情况,如果该skuId刚好存在在时间维度上共享的库存记录,而查询请求中的时间段,与库存记录中的时间段可能并不是完全一致的,此时,为了保证查询结果的准确率,可以首先判断查询请求中指定的时间段是否与库存记录对应的指定时间段存在重叠,如果存在重叠,就可以将该库存记录返回。当然,在实际应用中,两个时间段可能出现的重叠方式可能有多种,只要满足其中任意一种重叠方式,就可以判定为两者存在重叠。具体实现时,首先可以根据各种可能出现的重叠方式分别生成对应的判断语句,如果查询请求中指定的时间段的开始时间、结束时间,以及库存记录对应的指定时间段的开始时间、结束时间之间的关系满足任一判断语句,则判定查询请求中指定的时间段与库存记录对应的指定时间段存在重叠。
例如,假设IS代表查询请求中指定时间段的开始时间,IE代表查询请求中指定时间段的结束时间,ST代表库存记录中共享时间段的开始时间,ET代表库存记录中共享时间段的结束时间。则各种可能的重叠方式以及各种的判断语句可以如图2中。例如,某库存记录A中共享时间段为7月2日至7月6日,而用户查询的时间段为7月3日至7月5日,则符合图2中的第一个场景,因此,可以将该库存记录A返回给用户;如果用户查询的时间段为7月1日至7月7日,则符合图2中的第二个场景,此时,如果对应的sku在7月1日和/或7月7日还存在相应的库存记录,则可以在将该库存记录A返回给用户的同时,将7月1日和/或7月7日的库存记录也一并返回给用户;如果用户查询的时间段为7月3日至7月7日,则符合图2中的第三个场景,如果用户查询的时间段为7月1日至7月5日,则符合图2中的第四个场景,具体返回的查询结果与前述两种场景类似。
当然为了提高判断的效率,可以将这四种判断语句组合起来进行高效的判断,例如,组合的方式可以是:
(where ST<=IS and ET>=IE)union all(
where ST>=IS and ET<=IE)union all(
where ST<=IS and ET<=IE)union all(
where ST>=IS and ET>=IE)
其中的union all用一个判断语句合并:
ST<=IE and ET>=IS即start_time<=input_e and end_time>=input_s
另外需要说明的是,在本申请实施例中,由于将一个商品对象的库存记录拆分成了多条,可能会使得数据库中的库存记录条目数量非常庞大。例如,一般而言,一个商品对象的sku可能会达到30个sku甚至更多,最多可以设置90天的库存,则一个商品最多可能会对应30×90=1800条库存记录。而如果对这些库存记录的所有访问操作都在数据库中进行,则可能会由于对数据库的频繁访问而造成性能下降等问题。因此,在本申请实施例中,还可以将商品对象的各条库存记录写入到结构化存储的缓存(LDB)中,LDB与普通缓存的区别在于,其为一种结构化的缓存,数据结构包括主键(key)、子key以及对应的值(value),另外,其为一种持久化的缓存,如果系统发生重启或者宕机,其中的数据仍然存在,还可以进行读取。而本申请实施例中,各条库存记录恰好可以适应LDB中的结构化特点,例如,可以以商品对象标识+sku标识作为主key,以时间信息作为子key,具体的库存数量作为value。
这样,对库存记录的查询操作就可以在LDB中进行,提高查询效率。当然,由于LDB对事务不支持,而对库存记录的一些修改编辑操作则一般需要在一定的事务中进行,例如,第一用户需要插入一条库存,同时可能需要操作主sku与子sku的关联关系表,等等。因此,在具体实现时,对于涉及到对库存记录进行修改编辑的操作,可以仍然是在数据库中进行,修改编辑完成之后再将更新后的库存记录同步更新到LDB,供后续的查询使用。
总之,在本申请实施例中,对于同一商品对象,可以生成多条库存记录,其中,对于不需要进行共享的库存信息,可以以商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存信息进行存储,这样,在对某一sku的某一时间点中的库存信息进行访问时,可以仅取出这条库存记录,其他的库存记录不受影响,因此有利于提高系统性能,同时也方便在时间或者sku上进行关联。其中,如果需要在时间维度上共享库存信息,则可以以商品对象的指定时间段对应一条库存记录的方式,对库存信息进行存储,并在库存记录中记录共享的开始时间以及结束时间;对于需要在sku维度上共享的库存信息,确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并在第三库存记录中记录主sku与共享的库存数量之间的对应关系;如果同时还需要在时间维度上共享,则还在所述第三库存记录中记录共享的开始时间以及结束时间。最终接收到访问指定商品对象的库存记录的请求时,就可以根据请求中指定的时间和/或sku信息,读取对应的库存记录,并按照请求进行处理。因此,在存在时间和/或sku维度上共享库存信息的情况下,在对库存记录进行修改、查询等过程中,能够保证库存数量的准确性。
实施例二
在实际应用中,可能存在第一用户仅为某商品对象设置某一类型的库存记录的情况,例如,可能仅需要在某几个指定的sku之间共享。因此,在本申请实施例二中,对这种情况进行介绍。参见图3,该实施例二提供的商品对象库存信息处理方法可以包括以下步骤:
S301:接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在最小销售属性sku维度上共享的库存数量以及指定共享的至少两个sku;
S302:根据该商品对象的标识信息定位到该商品对象的库存信息;
S303:从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
S304:通过以下方式对该商品对象的库存信息进行更新存储:以一个主sku对应一条库存记录的方式,对该商品对象需要在所述sku维度上共享的库存数量进行存储。
在接收到第二用户访问该商品对象的库存数量的第二请求时,可以根据第二请求中指定的sku信息,读取与所述指定的sku信息相匹配的库存记录,并按照第二请求中的指令对所述相匹配的库存记录进行处理;其中,如果不存在与所述指定的sku信息匹配的库存记录,但所述指定的sku信息出现在主sku与子sku之间的关联关系中,则可以读取该主sku对应的库存记录,并按照第二请求中的指令对该主sku对应的库存记录进行处理。
通过本申请实施例二,如果需要在sku维度上实现库存数量的共享,则可以确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并仅记录主sku与共享的库存数量之间的对应关系,子sku不再出现在库存记录中。这样,后续在对存在sku维度的共享关系的库存记录进行修改的过程中,可以通过查询主sku与子sku之间的关联关系,将用户发起的对子sku的库存记录进行修改的请求,转换为对主sku的库存记录进行修改,从而能够保证库存数量的准确性。
实施例三
该实施例三对第一用户仅需要在sku以及时间这两个维度上同时共享某库存信息的情况进行介绍。参见图4,该实施例三提供的商品对象库存信息处理方法可以包括以下步骤:
S401:接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在时间与最小销售属性sku两个维度上共享的库存数量以及指定共享的开始时间、结束时间及至少两个sku;
S402:根据该商品对象的标识信息定位到该商品对象的库存信息;
S403:从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
S404:通过以下方式对该商品对象的库存信息进行更新存储:以主sku加时间段信息对应一条库存记录的方式,对该商品对象需要在时间与sku两个维度上共享的库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
当接收到第二用户访问该商品对象的库存数量的第二请求时,可以根据第二请求中指定的时间以及sku信息,读取与指定的时间以及sku信息相匹配的库存记录,并按照第二请求中的指令对所述相匹配的库存记录进行处理;其中,如果不存在与指定的sku信息匹配的库存记录,但指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的库存记录,如果指定的时间信息落在该主sku对应的库存记录中开始时间以及结束时间范围内,则按照第二请求中的指令对该主sku对应的库存记录进行处理。
其中,如果第二请求中指定的时间信息是一时间段,则可以判断第二请求中指定的时间段是否与某库存记录开始时间以及结束时间组成的时间段存在重叠,如果是,则将该库存记录判定第二请求中指定的时间信息落在该主sku对应的库存记录中开始时间以及结束时间范围内。
通过该实施例三,如果需要在sku以及时间两个维度上实现库存数量的共享,则可以确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并仅记录主sku与共享的库存数量之间的对应关系,子sku不再出现在库存记录中。同时,还在主sku对应的库存记录中,保存共享的开始时间以及结束时间。这样,后续在对存在sku以及时间两个维度的共享关系的库存记录进行修改的过程中,可以通过查询主sku与子sku之间的关联关系,将用户发起的对子sku的库存记录进行修改的请求,转换为对主sku的库存记录进行修改,当然,在修改之前,还需要根据请求中的时间信息,判断是否位于共享的开始时间与结束时间组成的时间段范围之内。这样可以保证修改过程中,库存数量的准确性。
需要说明的是,关于实施例二以及实施三中的具体实现细节,分别在实施例一的步骤S104、S105中有相关的介绍,这里不再详述。另外,关于“将商品对象的各条库存记录写入到结构化存储的缓存中,针对第二用户的查询请求,在结构化存储的缓存中响应,针对第二用户的修改请求,则在数据库中进行响应”的相关信息,在该实施例二以及实施例三中也适用。
与本申请实施例二提供的商品对象库存信息处理方法相对应,本申请实施例还提供了一种商品对象库存信息处理系统,参见图5,该系统可以包括:
第一请求接收单元501,用于接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在最小销售属性sku维度上共享的库存数量以及指定共享的至少两个sku;
库存信息定位单元502,用于根据该商品对象的标识信息定位到该商品对象的库存信息;
关联关系记录单元503,用于从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
第一存储单元504,用于通过以下方式对该商品对象的库存信息进行更新存储:以一个主sku对应一条库存记录的方式,对该商品对象需要在所述sku维度上共享的库存数量进行存储。
与本申请实施例三提供的商品对象库存信息处理方法相对应,本申请实施例还提供了一种商品对象库存信息处理系统,参见图6,该系统可以包括:
第一请求接收单元601,用于接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在时间与最小销售属性sku两个维度上共享的库存数量以及指定共享的开始时间、结束时间及至少两个sku;
库存信息定位单元602,用于根据该商品对象的标识信息定位到该商品对象的库存信息;
关联关系记录单元603,用于从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
第二存储单元604,用于通过以下方式对该商品对象的库存信息进行更新存储:以主sku加时间段信息对应一条库存记录的方式,对该商品对象需要在时间与sku两个维度上共享的库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
与本申请实施例一提供的商品对象库存信息处理方法相对应,本申请实施例还提供了一种商品对象库存信息处理系统,参见图7,该系统可以包括:
第一请求接收单元701,用于接收第一用户为同一商品对象设置库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、不需要共享的库存数量和/或需要在指定维度上共享的库存数量,所述指定维度包括时间维度、最小销售属性sku维度中的一种或多种组合;
定位及存储单元702,用于根据该商品对象的标识信息定位到该商品对象的库存信息,并根据所述第一请求中携带的库存数量,对该商品对象的库存信息进行更新存储;
其中,所述定位存储单元702包括:
第一库存记录存储子单元7021,用于对于不需要共享的库存数量,以该商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存数量进行存储;
第二库存记录存储子单元7022,用于对于需要在时间维度上共享的库存数量,以一个时间段信息对应一条第二库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间;
第三库存记录存储子单元7023,用于对于需要在sku维度上共享的库存数量,从指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并以主sku对应一条第三库存记录的方式,对库存数量进行存储;
和/或,
第四库存记录存储子单元7024,用于对于需要在sku维度以及时间维度上共享的库存数量,指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,以主sku加时间段信息对应一条第四库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
需要说明的是,上述各个存储子单元7021至7024可能同时存在,也可能只出现其中的一个或者几个,具体可以根据第一用户提交的第一请求中携带的信息情况而定。
具体实现时,该系统还可以包括:
处理单元,用于接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间和/或sku信息,读取与所述指定的时间和/或sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理。
其中,处理单元可以包括:
第一处理子单元,用于如果第二请求中指定的时间落在所述第二库存记录/第四库存记录中记录的开始时间以及结束时间范围内,则读取所述第二库存记录/第四库存记录,并按照所述第二请求中的指令对所述第二库存记录/第四库存记录中的库存信息进行处理。
第二处理子单元,用于如果不存在与所述指定的sku信息匹配的库存记录,且指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的第三库存记录/第四库存记录,并按照所述第二请求中的指令,对该第三库存记录/第四库存记录中的库存信息进行处理。
第三处理子单元,用于如果不存在与第二请求中指定的sku信息匹配的库存记录,但所述指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的第四库存记录,如果第二请求中指定的时间信息落在该第四库存记录中开始时间以及结束时间范围内,则按照所述第二请求中的指令对该第四库存记录中的库存信息进行处理。
所述第二请求包括修改指定商品对象的库存记录的请求;或者,查询指定商品对象的库存记录的请求。
接收到查询指定商品对象的库存记录的请求时,如果查询请求中指定的时间信息是一时间段,且所述指定商品对象的库存记录中存在与该时间段相匹配的第二库存记录/第四库存记录,则处理单元具体可以用于:判断所述查询请求中指定的时间段是否与所述第二库存记录/第四库存记录中记录的时间段存在重叠,如果是,则读取所述第二库存记录/第四库存记录并返回。
具体实现时,可以预先根据各种可能出现的重叠方式分别生成对应的判断语句,这样,如果所述查询请求中指定的时间段的开始时间、结束时间,与第二库存记录/第四库存记录中记录的时间段的开始时间、结束时间之间的关系满足任一判断语句,则判定所述查询请求中指定的时间段与所述第二库存记录/第四库存记录中记录的时间段存在重叠。
为了提高效率,可以将商品对象的各条库存记录写入到结构化存储的缓存中,其中,以商品对象标识加sku标识作为主键,以时间信息作为子键;处理单元具体可以用于接收到查询指定商品对象的库存记录的请求时,根据请求中指定的时间和/或sku信息,从所述结构化存储的缓存中读取相匹配的库存记录并返回。另外,接收到修改指定商品对象的库存记录的请求时,根据请求中指定的时间和/或sku信息,从数据库中读取相匹配的库存记录,并按照请求对库存记录进行修改。
总之,在本申请实施例中,如果需要在sku维度上实现库存数量的共享,则可以确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并仅记录主sku与共享的库存数量之间的对应关系,子sku不再出现在库存记录中。这样,后续在对存在sku维度的共享关系的库存记录进行修改的过程中,可以通过查询主sku与子sku之间的关联关系,将用户发起的对子sku的库存记录进行修改的请求,转换为对主sku的库存记录进行修改,从而能够保证库存数量的准确性。
另外,对于同一商品对象,可以生成多条库存记录,其中,对于不需要进行共享的库存信息,可以以商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存信息进行存储,这样,在对某一sku的某一时间点中的库存信息进行访问时,可以仅取出这条库存记录,其他的库存记录不受影响,因此有利于提高系统性能,同时也方便在时间或者sku上进行关联。其中,如果需要在时间维度上共享库存信息,则可以以商品对象的指定时间段对应一条库存记录的方式,对库存信息进行存储,并在库存记录中记录共享的开始时间以及结束时间;对于需要在sku维度上共享的库存信息,确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并在第三库存记录中记录主sku与共享的库存数量之间的对应关系;如果同时还需要在时间维度上共享,则还在所述第三库存记录中记录共享的开始时间以及结束时间。最终接收到访问指定商品对象的库存记录的请求时,就可以根据请求中指定的时间和/或sku信息,读取对应的库存记录,并按照请求进行处理。因此,在存在时间和/或sku维度上共享库存信息的情况下,在对库存记录进行修改、查询等过程中,能够保证库存数量的准确性。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统或系统实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上对本申请所提供的商品对象库存信息处理方法及系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处。综上所述,本说明书内容不应理解为对本申请的限制。
Claims (18)
1.一种商品对象库存信息处理方法,其特征在于,包括:
接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在最小销售属性sku维度上共享的库存数量以及指定共享的至少两个sku;
根据该商品对象的标识信息定位到该商品对象的库存信息;
从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
通过以下方式对该商品对象的库存信息进行更新存储:以一个主sku对应一条库存记录的方式,对该商品对象需要在所述sku维度上共享的库存数量进行存储。
2.根据权利要求1所述的方法,其特征在于,还包括:
接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的sku信息,读取与所述指定的sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理;其中,如果不存在与所述指定的sku信息匹配的库存记录,但所述指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的库存记录,并按照所述第二请求中的指令对该主sku对应的库存记录进行处理。
3.一种商品对象库存信息处理方法,其特征在于,包括:
接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在时间与最小销售属性sku两个维度上共享的库存数量以及指定共享的开始时间、结束时间及至少两个sku;
根据该商品对象的标识信息定位到该商品对象的库存信息;
从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
通过以下方式对该商品对象的库存信息进行更新存储:以主sku加时间段信息对应一条库存记录的方式,对该商品对象需要在时间与sku两个维度上共享的库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
4.根据权利要求3所述的方法,其特征在于,还包括:
接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间以及sku信息,读取与所述指定的时间以及sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理;其中,如果不存在与所述指定的sku信息匹配的库存记录,但所述指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的库存记录,如果所述指定的时间信息落在该主sku对应的库存记录中开始时间以及结束时间范围内,则按照所述第二请求中的指令对该主sku对应的库存记录进行处理。
5.根据权利要求4所述的方法,其特征在于,如果所述第二请求中指定的时间信息是一时间段,则判断所述第二请求中指定的时间段是否与某库存记录开始时间以及结束时间组成的时间段存在重叠,如果是,则判定所述指定的时间信息落在该主sku对应的库存记录中开始时间以及结束时间范围内。
6.一种商品对象库存信息处理方法,其特征在于,包括:
接收第一用户为同一商品对象设置库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、不需要共享的库存数量和/或需要在指定维度上共享的库存数量,所述指定维度包括时间维度、最小销售属性sku维度中的一种或多种组合;
根据该商品对象的标识信息定位到该商品对象的库存信息,并根据所述第一请求中携带的库存数量,对该商品对象的库存信息进行更新存储,其中:
对于不需要共享的库存数量,以该商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存数量进行存储;
对于需要在时间维度上共享的库存数量,以一个时间段信息对应一条第二库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间;
对于需要在sku维度上共享的库存数量,从指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并以主sku对应一条第三库存记录的方式,对库存数量进行存储;
和/或,
对于需要在sku维度以及时间维度上共享的库存数量,指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,以主sku加时间段信息对应一条第四库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
7.根据权利要求6所述的方法,其特征在于,还包括:
接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间和/或sku信息,读取与所述指定的时间和/或sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理。
8.根据权利要求7所述的方法,其特征在于,所述接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间和/或sku信息,读取与所述指定的时间和/或sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理,包括:
如果第二请求中指定的时间落在所述第二库存记录/第四库存记录中记录的开始时间以及结束时间范围内,则读取所述第二库存记录/第四库存记录,并按照所述第二请求中的指令对所述第二库存记录/第四库存记录中的库存信息进行处理。
9.根据权利要求7所述的方法,其特征在于,所述接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间和/或sku信息,读取与所述指定的时间和/或sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理,包括:
如果不存在与所述指定的sku信息匹配的库存记录,且指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的第三库存记录/第四库存记录,并按照所述第二请求中的指令,对该第三库存记录/第四库存记录中的库存信息进行处理。
10.根据权利要求7所述的方法,其特征在于,所述接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间和/或sku信息,读取与所述指定的时间和/或sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理,包括:
如果不存在与第二请求中指定的sku信息匹配的库存记录,但所述指定的sku信息出现在主sku与子sku之间的关联关系中,则读取该主sku对应的第四库存记录,如果第二请求中指定的时间信息落在该第四库存记录中开始时间以及结束时间范围内,则按照所述第二请求中的指令对该第四库存记录中的库存信息进行处理。
11.根据权利要求7至10任一项所述的方法,其特征在于,所述第二请求包括修改指定商品对象的库存记录的请求;或者,查询指定商品对象的库存记录的请求。
12.根据权利要求11所述的方法,其特征在于,接收到查询指定商品对象的库存记录的请求时,如果查询请求中指定的时间信息是一时间段,且所述指定商品对象的库存记录中存在与该时间段相匹配的第二库存记录/第四库存记录,则所述接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间和/或sku信息,读取与所述指定的时间和/或sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理,包括:
判断所述查询请求中指定的时间段是否与所述第二库存记录/第四库存记录中记录的时间段存在重叠,如果是,则读取所述第二库存记录/第四库存记录并返回。
13.根据权利要求12所述的方法,其特征在于,预先根据各种可能出现的重叠方式分别生成对应的判断语句;所述判断所述查询请求中指定的时间段是否与所述第二库存记录/第四库存记录中记录的时间段存在重叠,包括:
如果所述查询请求中指定的时间段的开始时间、结束时间,与第二库存记录/第四库存记录中记录的时间段的开始时间、结束时间之间的关系满足任一判断语句,则判定所述查询请求中指定的时间段与所述第二库存记录/第四库存记录中记录的时间段存在重叠。
14.根据权利要求7至10任一项所述的方法,其特征在于,还包括:
将商品对象的各条库存记录写入到结构化存储的缓存中,其中,以商品对象标识加sku标识作为主键,以时间信息作为子键;
所述接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间和/或sku信息,读取与所述指定的时间和/或sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理,包括:
接收到查询指定商品对象的库存记录的请求时,根据请求中指定的时间和/或sku信息,从所述结构化存储的缓存中读取相匹配的库存记录并返回。
15.根据权利要求14所述的方法,其特征在于,所述接收到第二用户访问该商品对象的库存数量的第二请求时,根据第二请求中指定的时间和/或sku信息,读取与所述指定的时间和/或sku信息相匹配的库存记录,并按照所述第二请求中的指令对所述相匹配的库存记录进行处理,还包括:
接收到修改指定商品对象的库存记录的请求时,根据请求中指定的时间和/或sku信息,从数据库中读取相匹配的库存记录,并按照请求对库存记录进行修改。
16.一种商品对象库存信息处理系统,其特征在于,包括:
第一请求接收单元,用于接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在最小销售属性sku维度上共享的库存数量以及指定共享的至少两个sku;
库存信息定位单元,用于根据该商品对象的标识信息定位到该商品对象的库存信息;
关联关系记录单元,用于从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
第一存储单元,用于通过以下方式对该商品对象的库存信息进行更新存储:以一个主sku对应一条库存记录的方式,对该商品对象需要在所述sku维度上共享的库存数量进行存储。
17.一种商品对象库存信息处理系统,其特征在于,包括:
第一请求接收单元,用于接收第一用户为商品对象设定库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、需要在时间与最小销售属性sku两个维度上共享的库存数量以及指定共享的开始时间、结束时间及至少两个sku;
库存信息定位单元,用于根据该商品对象的标识信息定位到该商品对象的库存信息;
关联关系记录单元,用于从所述至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系;
第二存储单元,用于通过以下方式对该商品对象的库存信息进行更新存储:以主sku加时间段信息对应一条库存记录的方式,对该商品对象需要在时间与sku两个维度上共享的库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
18.一种商品对象库存信息处理系统,其特征在于,包括:
第一请求接收单元,用于接收第一用户为同一商品对象设置库存信息的第一请求,所述第一请求中携带有该商品对象的标识信息、不需要共享的库存数量和/或需要在指定维度上共享的库存数量,所述指定维度包括时间维度、最小销售属性sku维度中的一种或多种组合;
定位及存储单元,用于根据该商品对象的标识信息定位到该商品对象的库存信息,并根据所述第一请求中携带的库存数量,对该商品对象的库存信息进行更新存储;
其中,所述定位及存储单元包括:
第一库存记录存储子单元,用于对于不需要共享的库存数量,以该商品对象的一个sku加一个时间点对应一条第一库存记录的方式,对库存数量进行存储;
第二库存记录存储单元,用于对于需要在时间维度上共享的库存数量,以一个时间段信息对应一条第二库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间;
第三库存记录存储单元,用于对于需要在sku维度上共享的库存数量,从指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,并以主sku对应一条第三库存记录的方式,对库存数量进行存储;
和/或,
第四库存记录存储单元,用于对于需要在sku维度以及时间维度上共享的库存数量,指定共享的至少两个sku中确定其中一个sku为主sku,其他sku为子sku,记录主sku与子sku之间的关联关系,以主sku加时间段信息对应一条第四库存记录的方式,对库存数量进行存储,所述时间段信息包括共享的开始时间以及结束时间。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310452911.3A CN104516895B (zh) | 2013-09-27 | 2013-09-27 | 商品对象库存信息处理方法及系统 |
HK15105325.8A HK1204813A1 (zh) | 2013-09-27 | 2015-06-04 | 商品對象庫存信息處理方法及系統 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310452911.3A CN104516895B (zh) | 2013-09-27 | 2013-09-27 | 商品对象库存信息处理方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104516895A CN104516895A (zh) | 2015-04-15 |
CN104516895B true CN104516895B (zh) | 2018-04-20 |
Family
ID=52792209
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310452911.3A Active CN104516895B (zh) | 2013-09-27 | 2013-09-27 | 商品对象库存信息处理方法及系统 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN104516895B (zh) |
HK (1) | HK1204813A1 (zh) |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106156975A (zh) * | 2015-04-23 | 2016-11-23 | 阿里巴巴集团控股有限公司 | 业务对象的库存信息处理方法及装置 |
CN106156242A (zh) * | 2015-04-27 | 2016-11-23 | 阿里巴巴集团控股有限公司 | 实现及时更新网站发布对象的数量的方法和装置 |
CN106326243B (zh) * | 2015-06-19 | 2020-02-21 | 苏宁云计算有限公司 | 一种数据处理方法及装置 |
WO2017010804A1 (en) * | 2015-07-15 | 2017-01-19 | Samsung Electronics Co., Ltd. | Object recognition for a storage structure |
CN105608617A (zh) * | 2016-01-06 | 2016-05-25 | 广州唯品会信息科技有限公司 | 商品详情页联动显示方法和系统 |
CN105956120A (zh) * | 2016-05-05 | 2016-09-21 | 北京票之家科技有限公司 | 产品库存更新方法及装置 |
CN108108378B (zh) * | 2016-11-24 | 2023-04-07 | 阿里巴巴集团控股有限公司 | 数据对象库存信息处理方法及装置 |
CN108874805B (zh) * | 2017-05-09 | 2022-05-20 | 腾讯科技(北京)有限公司 | 数据的处理方法和装置 |
CN107944991A (zh) * | 2017-12-29 | 2018-04-20 | 广州天高软件科技有限公司 | 一种对门票产品进行销售的在线票务系统 |
CN108109018B (zh) * | 2018-01-12 | 2022-05-17 | 山东车盟电子商务有限公司 | 基于sku信息列表的b2b电商精准营销方法 |
CN109447293B (zh) * | 2018-09-21 | 2021-05-04 | 口碑(上海)信息技术有限公司 | 一种产品数据的处理方法及装置 |
CN111260272A (zh) * | 2019-12-02 | 2020-06-09 | 泰康保险集团股份有限公司 | 基于库存响应用户请求的方法、装置、设备及存储介质 |
CN112416314A (zh) * | 2020-01-21 | 2021-02-26 | 上海哔哩哔哩科技有限公司 | 库存动态管理方法及系统 |
TWI764305B (zh) * | 2020-09-30 | 2022-05-11 | 中華電信股份有限公司 | 群組訂單連動式管理方法 |
CN113780917B (zh) * | 2020-11-30 | 2023-11-03 | 北京京东振世信息技术有限公司 | 货物调度方法和系统 |
CN116567281A (zh) * | 2023-04-19 | 2023-08-08 | 上海百秋智尚网络服务有限公司 | 直播交互方法、装置、设备及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1615487A (zh) * | 2002-01-23 | 2005-05-11 | 雀巢技术公司 | 用于库存管理的系统和方法 |
CN1656488A (zh) * | 2001-08-17 | 2005-08-17 | 艾克斯佩迪亚公司 | 管理库存的系统和方法 |
CN103177353A (zh) * | 2011-12-26 | 2013-06-26 | 深圳光启高等理工研究院 | 库存变化处理方法及装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040182924A1 (en) * | 2003-03-19 | 2004-09-23 | In Zone Brands, Inc. | Method of grouping retail products for distribution and inventory control |
US20060224422A1 (en) * | 2005-02-25 | 2006-10-05 | Cohen Ralph B | System and method for applying for insurance at a point of sale |
-
2013
- 2013-09-27 CN CN201310452911.3A patent/CN104516895B/zh active Active
-
2015
- 2015-06-04 HK HK15105325.8A patent/HK1204813A1/zh unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1656488A (zh) * | 2001-08-17 | 2005-08-17 | 艾克斯佩迪亚公司 | 管理库存的系统和方法 |
CN1615487A (zh) * | 2002-01-23 | 2005-05-11 | 雀巢技术公司 | 用于库存管理的系统和方法 |
CN103177353A (zh) * | 2011-12-26 | 2013-06-26 | 深圳光启高等理工研究院 | 库存变化处理方法及装置 |
Non-Patent Citations (1)
Title |
---|
资源型企业共享库存管理模式研究;李士金等;《科技和产业》;20111031;第11卷(第10期);第58-61页 * |
Also Published As
Publication number | Publication date |
---|---|
CN104516895A (zh) | 2015-04-15 |
HK1204813A1 (zh) | 2015-12-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104516895B (zh) | 商品对象库存信息处理方法及系统 | |
US10878052B2 (en) | Blockchain-based cross-chain data operation method and apparatus | |
US10877930B2 (en) | Blockchain-based cross-chain data access method and apparatus | |
CN104794132B (zh) | 库存信息处理方法及系统 | |
CN104699712B (zh) | 对数据库中的库存记录信息进行更新的方法及装置 | |
CN104598459B (zh) | 数据库处理、数据访问方法及系统 | |
US5873096A (en) | Method of maintaining a network of partially replicated database system | |
US7539689B2 (en) | Bundling database | |
CN101566986A (zh) | 联机事务处理中的数据处理方法和装置 | |
JP2001513926A (ja) | 複数レベルのリモート・クライアントを持つ部分的複製分散データベース | |
TWI745702B (zh) | 資料查詢方法、裝置、電子設備及電腦可讀儲存媒體 | |
US7461065B2 (en) | Method and system for utilizing shared numeric locks | |
US9342812B2 (en) | Taxonomy based database partitioning | |
CN106294402A (zh) | 一种异构数据源的数据搜索方法及其装置 | |
EP1010096B1 (en) | Method of maintaining a network of partially replicated database system | |
CN104750749B (zh) | 数据处理方法及装置 | |
JP3444111B2 (ja) | 商品情報表示方法およびシステム | |
CN105339961A (zh) | 分层管理门户 | |
CN110782313B (zh) | 一种基于分库分表的数据库事务处理方法及装置 | |
CN102193986A (zh) | 图形数据库中联机事务的实现方法 | |
Quinn | Making sense of the graph revolution | |
CN110750525A (zh) | 基于海关大数据及谷歌搜索的获客方法和系统和设备 | |
CN103336804A (zh) | 一种学术论文高效分配方法 | |
JP2000222434A (ja) | 結合検索方法 | |
Michailidis | Development of a Smart Ordering System |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1204813 Country of ref document: HK |
|
GR01 | Patent grant | ||
GR01 | Patent grant |