波仔
🗄️ 第一章 数据库的基础知识
📄 一句话概括

一家超市的一台收银机背后，至少有查询商品、写入销售记录、汇总分析三套数据库动作在流转——POS、订单、分析就是数据库最典型的三个用武之地。

📝 本节和前面几节的关系

1-6 学会了【怎么对数据库说话】；本节第一次把前六节全部串进真实商业场景——收银是【查＋写】、订单是【增删改】、分析是【查询的统计版】，教材标题里的三个词正好对应三种动作。

一、POS 收银机：一次【查询＋登记】

POS（Point of Sales，销售终端）就是超市收银台那台扫码机。它每扫一件商品，背后发生两步：

  1. 查：拿着条形码去商品表里找——【6901234567890 是什么？多少钱？】（一条 SELECT）
  2. 写：结账瞬间往销售记录表里插一行——几点、什么商品、几件、多少钱（一条 INSERT）

所以收银机的本职身份是：一个连着数据库的终端。它自己不存货、不存账——商品数据和销售数据全在后台数据库里。

二、订单管理：增删改的主战场

外卖、网购的订单系统，一天到晚都在做 1-6 说的【操作三件套】：

动作 用户视角 数据库动作
下单 点【提交订单】 INSERT 一条订单
改地址 订单详情里【修改地址】 UPDATE 那一行
取消订单 点【取消】 DELETE（或把状态字段改成【已取消】）

注意最后一行的括号——实际系统更爱用【改状态】而不是真删：订单记录是经营凭证，通常留着不删，只是标记作废。这也是 1-2【登记】精神的体现：商业数据要可追溯。

三、分析：查询的统计版

月底店长要一份报表：【本月卖得最好的前 10 名商品】。

同一个数据库，白天支撑收银（日常业务），月底支撑报表（分析决策）——两种用法共用一套数据，这正是【可共享】的价值。

四、三套动作连成一条线

顾客扫码 ──查──▶ 商品表（价格）
    │
    └─结账─写─▶ 销售记录表 ──月底统计──▶ 分析报表
                    │
外卖/网购订单 ──增删改──▶ 订单表

一条链上，1-2 的【登记/整理/查询】、1-4 的【限制（金额不许为空）/控制（收银高峰几十台 POS 同时写）/恢复（账目坏了照日志找回）】全部在岗。

五、动手 Demo：拿一张超市小票逐行对表

找出最近一张超市小票，逐行回答【它动了哪张表】：

小票上的内容 动了哪张表 干了什么
商品名＋单价 商品表 结账前查询（SELECT）
每行【品名×数量×金额】 销售记录表 结账时写入（INSERT）
会员积分变化 会员表 结账时更新（UPDATE）
底部【合计/找零】 ——（计算结果） 由查询结果算出

看到什么算成功：小票每一行都能归到某张表、某个动作上——你就具备了【看见小票，看穿数据库】的眼睛。

六、30 秒实验

下次结账时盯一下收银屏：从【滴】的一声到价格跳出来，中间几乎感觉不到延迟。

七、常见误区

  1. "收银机里存着全部商品数据" —— 收银机只是终端；商品数据在后台数据库，它每次都是现场查。所以换一台 POS 扫码照样能扫——【货】不在机子里，在库里。
  2. "做分析要把数据另外抄一份" —— 通常就查同一个库（或定期汇总一份）。同一套数据既管日常又做分析，不必手工搬运。
  3. "小票就是数据库记录" —— 小票只是给顾客的打印凭条；真正的记录是销售表里那一行数据，小票弄丢了记录还在。
自测三问（点开对答案） 1. POS 扫码一次，背后是哪两个数据库动作？ **查商品表（SELECT）＋ 写销售记录（INSERT）**。 2. 取消订单更常见做法是真删吗？ **不是**——把状态字段改成【已取消】，记录保留以便追溯。 3. 月底报表的【原料】和【成品】分别是什么？ **原料＝销售记录（数据），成品＝报表结论（信息）**——呼应 1-1。

相关笔记