动态列数据库设计：如何为商户关联产品设置价格属性

定价、库存可用状态这类与「店铺-产品关联关系强绑定的属性，直接存入你已有的用户-产品关联中间表，无需放入products或users主表

设计逻辑依据 #

• 先明确各表的属性边界，避免数据归属错乱：
  • products表是系统管理员维护的全局产品主数据，仅存储全店铺通用的产品固有属性（如产品ID、标准化规格、全局参考成本等）。如果把单店铺的售价放在这里，完全无法支持同一产品在不同店铺设置不同定价的业务需求，还会突破权限边界让普通用户误改全局主数据
  • users表存储用户/店铺的全局身份属性（如账号ID、店铺名称、经营资质等），单产品的定价和店铺全局属性无关，强行塞入会产生大量无效空值，不符合数据库设计的基本范式
  • 关联中间表的本质是存储「某用户/店铺和某产品的绑定关系」，所有依附于这个绑定关系的差异化配置，天生就属于这张表的存储范围

关联表的字段设计参考 #

你可以把当前的通用中间表重命名为更贴合业务语义的user_product_shop_config，除了已有的关联字段，直接补充业务需要的配置字段：

• user_id：关联users表的外键，与product_id组成表的联合主键，避免同一店铺重复绑定同一产品
• product_id：关联products表的外键
• shop_price：采用decimal类型存储（禁止使用float/double避免精度误差），存储当前店铺为该产品设置的专属售价
• stock_available：采用tinyint/布尔类型存储，标记该产品在当前店铺的可售状态
• 可选补充字段：config_updated_at存储最近配置修改时间、config_updated_by存储操作人ID，满足日常审计需求

避坑提醒 #

不要为了所谓的「动态列」需求强行采用EAV（实体-属性-值）键值扩展表存储定价、库存这类核心业务字段：这两个字段是业务规则明确、需要强数据校验（如价格不能为负、状态枚举值固定）的固定属性，不是无规则的自定义扩展字段，用EAV模型会大幅降低查询效率，也没法做有效的数据合法性约束
不要把定价字段拆分到独立的价格表：当前业务下每个店铺-产品关联关系对应唯一的在售定价，拆分独立表会增加不必要的关联查询成本，完全没有收益

设计匹配度验证 #

这套结构完全对齐你提到的业务权限规则：普通用户仅能操作自己user_id对应的关联记录的售价、库存字段，没有权限修改products表的全局产品数据，也无法新增/删除产品绑定关系（可以通过数据库权限控制把关联表的insert/delete权限收归管理员），完全符合「管理员统一维护产品主数据，普通用户仅做自有店铺的定价、库存配置」的流程

内容的提问来源于stack exchange，提问作者The Only Smart Boy