套餐数据优化那些事儿，数据库设计里怎么才能更顺手更高效

说到套餐数据优化，这其实是很多系统里都会碰到的一个典型问题，比如外卖平台上的各种美食套餐、电信运营商的手机套餐、或者健身房的各种会员套餐，这些套餐看起来简单，但在数据库里怎么存、怎么用,却直接影响到后面程序的难易程度和系统跑得快不快。

（一）一开始最容易掉进去的坑：把所有东西塞进一个字段

很多人刚开始设计的时候，图省事，可能会想：“一个套餐嘛，不就是包含几样东西吗？我在套餐表里直接加一个叫‘包含项目’的文本字段，然后把东西的名称和数量用逗号或者分号拼成一个字符串存进去，不就行了？” 比如一个“实惠午餐套餐”包含：宫保鸡丁1份，米饭1碗，可乐1杯，在数据库里就存成 “宫保鸡丁:1,米饭:1,可乐:1”。

这种做法听起来简单，但后患无穷，这是最需要避免的“坑”，为什么这么说呢？查询起来会变得极其困难，如果老板问：“有哪些套餐包含了‘米饭’？” 你的数据库查询语句会写得非常别扭，你得用上各种字符串查找函数，像在文章里找关键词一样，效率极低，而且很容易出错，修改起来也麻烦，如果顾客想把套餐里的可乐换成雪碧，你得先把整个字符串读出来，在程序代码里分割、查找、替换，然后再把整个字符串写回数据库，这个过程既繁琐又容易出错，如果同时有很多人修改，还可能产生数据混乱，这种结构几乎没办法做数据统计，你想分析一下“米饭”在所有套餐里的销售情况，根本无从下手,这个坑千万别跳。

（二）好一点的进步：用多个字段来存，但还是别扭

为了避免第一个坑，有些人会想：“那我给套餐表多设几个字段不就好了？项目1名称’，‘项目1数量’，‘项目2名称’，‘项目2数量’……” 这种方法确实比存成一个字符串要好一点，至少查询某个具体项目时可以直接用等号来匹配,不需要处理字符串了。

但这种方法的问题在于“不灵活”，或者说“扩展性差”，你一开始可能觉得一个套餐最多包含5样东西，所以就设计了5对字段，但万一后来出了一个“豪华全家桶”套餐，包含了15样东西，你的表结构就傻眼了，需要修改数据库表结构（这通常是件大事），或者把多出来的东西再想办法塞回那个文本字段的“老路”上去，这就又乱套了，即使对于只包含一两样东西的简单套餐，你设计的那些‘项目3名称’、‘项目4数量’字段也大多数是空着的，浪费了空间，查询时也要判断哪些字段是有效的，增加了复杂度，这种方法像是给数据穿了一件尺寸固定的紧身衣,稍微长胖点就穿不下了。

（三）更顺手高效的主流方法：拆分成两张表，建立关系

那到底怎么做才能又灵活又高效呢？答案是：利用关系型数据库的核心能力——“关系”，我们不要把套餐的所有内容都挤在一张表里,而是把它拆开。

第一张表：套餐基本信息表 这张表只负责记录套餐本身的核心信息，套餐ID（一个唯一的编号）、套餐名称、套餐价格、套餐描述等，它只管“套餐是谁”，不管“套餐里有什么”。

第二张表：套餐明细表 这张表专门用来记录每个套餐具体包含了什么，它至少需要三个字段：明细ID（可选的）、所属的套餐ID（这非常重要）、包含的项目ID（或名称）、该项目的数量。

这样一来，一个“实惠午餐套餐”（假设套餐ID是101）在数据库里可能是这样的：

• 套餐表里有一条记录：(ID: 101， 名称: 实惠午餐套餐， 价格: 30元)
• 套餐明细表里会有三条记录：
  • (套餐ID: 101， 项目名称: 宫保鸡丁， 数量: 1)
  • (套餐ID: 101， 项目名称: 米饭， 数量: 1)
  • (套餐ID: 101， 项目名称: 可乐， 数量: 1)

这种方法的好处一下子就体现出来了：

1. 查询极其灵活：老板再问“哪些套餐包含米饭？”，一句简单的SQL查询就能搞定：“从套餐明细表里找出项目名称是‘米饭’的所有记录，然后根据套餐ID找到对应的套餐信息”，速度快,逻辑清晰。
2. 扩展无忧：别说15样东西，就算150样，也只需要在明细表里增加150条记录就行了，完全不需要修改数据库的表结构，套餐内容的增、删、改都变成了对明细表里单条记录的操作,非常简单。
3. 利于统计：可以轻松地对明细表里的项目进行各种分析，比如哪个单品最受欢迎（被最多套餐包含）,等等。

（四）可以再优化：引入“标准化”思想

上面的方法已经非常实用了，如果想再进一步优化，可以考虑引入“标准化”的思想，你会发现，在明细表里，我们直接存了“项目名称”，宫保鸡丁”，但如果“宫保鸡丁”这个菜本身也有自己的属性，比如价格、成本、分类等，而且它可能不仅出现在这个套餐里，还会被单独售卖,那么直接把名字写死就不太合适了。

这时，我们可以再创建第三张表：项目信息表，这张表记录所有可能出现的单品的完整信息，项目ID、项目名称、单价、描述等。

我们把之前的“套餐明细表”里的“项目名称”字段，替换成“项目ID”，这样，明细表通过“项目ID”与“项目信息表”关联，这样做的好处是数据高度统一，宫保鸡丁”改名叫“经典宫保鸡丁”，你只需要在“项目信息表”里修改一次，所有引用了它的套餐都会自动更新，保证了数据的一致性,这也就是常说的数据库第三范式的一个简单应用。

让套餐数据设计更顺手高效的关键在于：

• 坚决不用一个字段存所有内容。
• 敢于把数据拆开，用“关系”来代替“堆砌”，核心就是“套餐表”+“套餐明细表”的模式。
• 根据业务复杂度，决定是否进一步拆出“项目表”来标准化基础数据。

这样做，前期设计时可能多花一点点时间，但后续的开发、维护和扩展都会变得非常顺畅，可以说是“磨刀不误砍柴工”的典型例子。