厨房里的数据库思维：服务端开发中的表结构设计

你有没有想过，做一顿饭和设计一个数据库其实挺像的？比如你要准备一桌家常菜，得先列清单：买多少肉、几斤青菜、要不要买鸡蛋。这就像服务端开发中设计数据库表结构，每一道菜是数据，食材是字段，菜单就是表。

从厨房备菜看数据分类

炒青菜需要蒜末、盐、青菜；红烧肉得有五花肉、酱油、糖。如果把所有食材混在一起记，下次做饭就乱套了。数据库也一样，用户信息不能和订单混在一张表里。常见的做法是拆分：用户表存手机号和昵称，订单表关联用户ID。

CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL,
  phone VARCHAR(15) UNIQUE
);

CREATE TABLE orders (
  id INT PRIMARY KEY AUTO_INCREMENT,
  user_id INT,
  dish_name VARCHAR(100),
  created_at DATETIME,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

索引就像调料柜的标签

你家的调料是不是都贴了标签？盐、鸡精、花椒各归其位。数据库里的索引也是这个道理。当你频繁按手机号查用户，就得给phone字段加索引，不然每次都要翻完整张表，跟找没标签的瓶子一样费劲。

但索引不是越多越好，就像你不会给每一粒米都贴标签。每多一个索引，写入数据时就会慢一点，维护成本上去，反而影响整体效率。

事务处理像做一锅炖菜

炖排骨要加水、放料、开火，这几个步骤必须一起完成，中间断了火，整锅就废了。数据库的事务也是这样，比如下单扣库存，必须同时成功或失败。用BEGIN、COMMIT、ROLLBACK来保证操作的完整性。

别让“大宽表”变成杂货铺

有人图省事，把用户地址、最近订单、积分全塞进一张大表里。这就像把锅碗瓢盆和衣服全堆在一个柜子里，看着方便，时间一长根本找不到东西。合理的范式设计能减少冗余，提升可维护性。

当然，也不是越规范越好。有时候为了查询快，适当冗余一点数据也行，比如在订单里直接存一份用户姓名，避免每次联表查询。这就像你提前把常用调料摆出来，虽然占点台面，但炒菜快。