BUFF 选品配置表设计思路

1. 背景与目标

当前行为：「BUFF选品」界面中的「保存配置信息」将检索条件（步枪、手枪、品质、外观、收藏品、排除/指定商品 id）与选品条件（Steam 卡价比例、利润率、BUFF 价格/销量区间、智能选品助手等级）保存到浏览器 localStorage，仅本机生效、换设备或清缓存即丢失。
目标：用数据库表持久化上述配置，实现「按用户存储、多端同步、可选多套配置」。

2. 数据范围梳理

需要落库的字段与前端 form 一致，分为两类：

类别	字段	类型	说明
检索条件	rifle, pistol, smg, shotgun, machinegun	string[]（存 JSON）	武器类型多选 value
	quality, category, exterior, collection	string[]（存 JSON）	品质/类别/外观/收藏品多选 value
	excludeIds	string	排除的商品 id，多行文本
	specifiedIds	string	指定商品 id，多行文本
选品条件	steamCardRatio	number	Steam 卡价比例
	profitRate	number	利润率（%）
	buffPriceMin, buffPriceMax	number	BUFF 价格区间
	buffSalesMin, buffSalesMax	number	BUFF 销量区间
	assistantLevel	string	智能选品助手：low/standard/high

3. 设计要点

3.1 与用户关联

配置必须按用户隔离，表中有 user_id（或等价登录标识），与现有 users 表一致。
未登录时仍可沿用「仅写 localStorage」或提示先登录再保存到云端。

3.2 单套 vs 多套配置

两种常见方式：

方案 A：每用户仅一套配置
- 一用户一行，每次保存覆盖。表结构简单，无需「配置名称」「默认配置」等字段。
方案 B：每用户多套配置（推荐）
- 一用户多行，每条配置有名称（如「默认」「高利润」「步枪专选」），便于区分场景；可增加 is_default 标记「当前默认加载哪一套」。

建议采用方案 B，便于后续扩展「配置列表 + 切换」而不必改表结构。

3.3 存储形式：JSON vs 纵表

JSON 一列存整份配置
- 优点：与前端 form 结构一致，扩展方便（新增筛选项或选品参数只需改前端，后端只存 JSON）。
- 缺点：无法按「某个筛选项」做 SQL 统计或检索。
纵表 / 多列
- 优点：可对单字段建索引、做统计。
- 缺点：字段多、表结构随前端 form 变更频繁，且多选数组仍需 JSON 或关联表。

推荐：主表 + 单列 JSON 存「检索条件 + 选品条件」。若未来需要对某几项做查询，再考虑在表上增加个别冗余列或独立统计表。

4. 推荐表结构（思路）

4.1 表名

buff_selection_config（BUFF 选品配置表）

4.2 字段建议

字段	类型	说明
id	bigint unsigned, PK, AUTO_INCREMENT	主键
user_id	int unsigned, NOT NULL	用户 ID，关联 users.id
name	varchar(64), NOT NULL	配置名称（如「默认」「高利润」），同用户下建议唯一
config_json	text/json, NOT NULL	整份配置的 JSON：包含 rifle、pistol、…、excludeIds、specifiedIds、steamCardRatio、profitRate、buffPriceMin/Max、buffSalesMin/Max、assistantLevel，与前端 form 结构一致
is_default	tinyint(1), DEFAULT 0	是否该用户的默认配置：0-否，1-是；同用户至多一个为 1
is_deleted	tinyint(1), DEFAULT 0	软删：0-否，1-是
created_at	datetime	创建时间
updated_at	datetime	更新时间

4.3 约束与索引

唯一约束：(user_id, name)，且仅当 is_deleted = 0 时唯一（若数据库支持条件唯一索引则可加，否则在业务层保证「同用户下未删除的 name 不重复」）。
索引：user_id、user_id + is_default（便于查某用户的默认配置）。

4.4 config_json 内容示例

与当前前端保存的 JSON 保持一致即可，例如：

{
  "rifle": ["weapon_ak47", "weapon_awp"],
  "pistol": [],
  "smg": [],
  "shotgun": [],
  "machinegun": [],
  "quality": ["ancient_weapon", "legendary_weapon"],
  "category": [],
  "exterior": ["wearcategory0", "wearcategory1"],
  "collection": ["set_community_36"],
  "excludeIds": "123\n456",
  "specifiedIds": "",
  "steamCardRatio": 0.85,
  "profitRate": 10,
  "buffPriceMin": 10,
  "buffPriceMax": 500,
  "buffSalesMin": null,
  "buffSalesMax": null,
  "assistantLevel": "standard"
}

5. 与现有流程的关系

保存：点击「保存配置信息」时，若已登录，可调后端接口：传 name（可选，默认如「默认」）、config_json、是否设为 is_default；后端按 user_id 写入或更新 buff_selection_config。
加载：进入「BUFF选品」页时，若已登录，可先请求「当前用户的默认配置」或「配置列表」，回填 form；未登录或未拉取到配置时，再回退到 localStorage。
本地与云端：可保留「先写 localStorage、再异步同步到服务端」的策略，减少未登录或网络异常时的体验损失。

6. 小结

项目	建议
表名	buff_selection_config
与用户	user_id 必填，按用户隔离
多套配置	支持，用 name 区分，is_default 标记默认
内容存储	单列 config_json，与前端 form 结构一致
软删	is_deleted，便于「删除」后保留历史或恢复

按此思路可实现「保存配置信息」落库、多端同步与多套配置，且与当前前端数据结构兼容，后续若要对部分字段做统计再在表或统计库中做冗余即可。

buff_selection_config_table_design.md 5.7 KB Histórico Raw