技术咨询：后端逻辑生成的条码编号应存储查询还是拆分查询？

你的条码是结构化生成的：前4位是category_id，中间段是product_id，最后2位是counter_id；数据库里每个产品占一行，包含5个counter列（对应12、34、56、78、90这五个固定值）。扫描条码后要查商品详情，下面给你分析两种方案的优劣和推荐：

方案一：存完整条码编号，直接按条码查询 #

• 好处：
  • 代码逻辑简单：扫到条码直接用WHERE barcode = '扫描到的编号'查询就行，不用做字符串拆分，减少出错概率。
  • 查询速度快：给barcode加唯一索引，精准匹配的查询效率拉满，数据量越大优势越明显。
• 弊端：
  • 存在冗余存储：条码是现有字段拼接生成的，额外存储属于冗余数据，不过单条数据占用空间极小，多数场景下可忽略。
  • 规则变动成本高：如果后续条码位数、结构调整，需要批量更新数据库中的旧条码，同时修改生成和查询逻辑。

方案二：拆分条码，用category_id+product_id+counter_id组合查询 #

• 好处：
  • 无冗余存储：不需要额外存储条码，直接用现有字段组合查询，节省存储空间。
  • 规则调整灵活：若后续条码结构变动，仅需修改拆分逻辑，无需改动数据库已有数据。
• 弊端：
  • 代码需额外处理：要先把扫描到的条码拆分为三个字段，还要做格式校验（比如检查条码长度是否合规，避免拆分错误）。
  • 查询性能需优化：由于counter分散在5个列中，查询时要写WHERE category_id = ? AND product_id = ? AND (counter1 = ? OR counter2 = ? OR ... OR counter5 = ?)，数据量大时多OR的查询会拖慢速度。若要优化，可能需要调整表结构——将5个counter列改为关联表（比如新建product_counters表，每条记录对应一个产品的一个counter），但这会涉及原有数据存储逻辑的修改。

推荐方案 #

• 如果条码规则短期内不会变动，且数据量较大，优先选方案一：查询简单高效，冗余存储的代价完全可控。
• 若条码规则可能调整，或不想有冗余数据，可选择方案二，但要做好拆分后的参数校验，必要时通过调整表结构优化counter的查询性能。

内容的提问来源于stack exchange，提问作者Charmi