配置

ItemId	MainType	SubType	MaxStackableCount
唯一Id	大类	小类	最大堆叠数

MainType：

主要的分类方式，不建议写入数据库

SubType：

MainType下面的分类方式，不建议写入数据库

MaxStackableCount:

为0时表示该Item不可堆叠；可用于处理各种Item的存储，当然有些时候，需要一种添加Item后不可改变数量的情况，具体可以根据业务设计

设计 

存储

UId	ItemId	Count
		拥有数量

基本的存储如上，但是这里有些问题需要考虑。如果Count为0，是否需要加载到内存？是否可以重用Count为0 的数据？建议不要重用Count为0的数据，就我遇到的情况，前期我们重用数据，但是后面发现一些生成的DbId, 被其它的系统依赖，当重用这些DbId, 就会出现添加的数据不是新数据，而有些业务又只处理新数据，在这里就出现了，对于某些业务新数据是有意义的，而有的却没有。当然如果不用背包做一些奇怪的系统以来，我觉得重用是完全没问题的，但是谁也保证不了

获取

一般来说玩家可以通过 MainType 和 itemId 获取相关的Item，数据量大的情况，建议细分查考下面链接

背包系统设计-获取数据量大问题-CSDN博客 

增减问题

如果存在好几个 未到 堆叠数数据，发生数量变化时怎样处理？应该加到谁身上？减到谁身上？

理论上，我们希望，减数据的时候先减 同itemId中 数量最小的；

                                加数据的时候先加 同itemId中 数量最多的；

这样可以保证尽量少的数据在内存中

bool TryRemoveItemCount(uint itemId, uint count)
{// 先检查是否足够// 获取这个类型的物品list, 按照数量递增排序int removeCount = remove;while(removeCount > 0){// 移除物品直到 removeCount 为0   }// 更新数据，推送等
}void AddItemCount(uint itemId, uint count)
{// 获取这个类型的物品list, 按照数量递减排序int addCount = remove;while(addCount > 0){// 添加物品直到 addCount 为0   }// 更新数据，推送等
}

 关联系统

这个系统算是所有系统的基础系统，不管是奖励的发放、还是其它业务，都是通过背包来工作的，但是不建议所有系统跟背包进行强关联，否则系统后期会很难维护，就像我们前期为了省事，考虑可能出现的各种交易，将所有的系统DbId跟背包关联，导致后期背包中存在很多无用的数据，而且一个数据存储在两个地方，本身就是违背设计的，但是由于各种原因，我们还是做了，希望大家做的时候想清楚，当然如果遇到一个喜欢应付的合作对象，你会发现，不管你怎样说他总有理由 ^ ^

奖励可以参考下面的链接

奖励Reward系统设计-CSDN博客