企业官网建设流程全解析

1. 为什么拿Northwind学数据更新最合适

做数据库相关的带教和答疑这么多年，我几乎每次需要验证一个想法、讲一个知识点，都会下意识把Northwind翻出来。这个经典的示例数据库表不多，关系却由浅入深，尤其适合讲“数据更新”这件事。

很多初学者觉得数据更新就是 INSERT、UPDATE、DELETE 三条句子背熟就行，可真到了项目里，改一条数据牵扯出来的东西远不止语法：外键约束、事务边界、锁等待、回滚机制、大表更新性能、数据一致性……这些如果没有一个趁手的练习库，很容易变成纸上谈兵。Northwind的表结构不大，但它有客户、商品、订单、订单明细、供应商、员工、类别这些典型业务对象，订单和明细之间的主外键关系，以及商品库存与订单明细之间的联动，恰好能把“更新”背后的约束和连锁反应完整地暴露出来。

所以这篇文章不是讲SQL语法手册，而是用Northwind当标本，把数据更新从单条语句一直讲到事务、并发、性能排查。适合刚学完基础SQL、想真正理解数据库更新机制的人，也适合带新人的开发者和准备面试前查漏补缺的工程师。读完你至少能把“为什么有时候一条UPDATE会卡住”“为什么删除订单要先删明细”“什么是事务的隔离级别”这类问题说清楚。

1.1 Northwind 的表结构和关系

先把这个库的地图在脑子里过一遍。Northwind主要包含这些核心表：

• Categories：商品分类
• Products：商品，包含单价、库存量、再订购点、供应商ID、分类ID
• Suppliers：供应商
• Customers：客户
• Orders：订单头，保存客户ID、下单日期、收货地址等
• Order Details：订单明细，保存商品ID、数量、单价、折扣
• Employees：员工，用于记录订单由谁负责
• Shippers：承运商

实际业务中最典型的关系是：Orders 和 Order Details 是一对多，Order Details 和 Products 是多对一，Products 和 Categories、Suppliers 是多对一。也就是说，一张订单要成立，客户、员工、承运商、商品都必须存在；一条订单明细要写入，订单头和商品也都必须在。

这种结构带来的直接后果就是更新一条数据往往不是“只改一行”那么简单。举一个最常见的例子：把一个商品的单价改了，已经存在的订单明细里存储的单价并不会跟着变，因为订单明细保存的是成交时的“快照”单价。这其实是设计上的有意为之，但换到初学者手里就容易疑惑，为什么改了Products表，历史订单里的价格还是老样子。

理解这个，才能真正理解数据更新中“源头数据”和“业务数据”的区别。Products是源头的参考数据，Order Details是交易快照数据，它们的更新规则不同、关联方式也不同。

1.2 “数据更新”到底在更新什么

我习惯把数据更新分成四个层次，这也是后面所有实操的思考框架：

第一层：单表行更新。按主键把某一行的某个字段改掉，比如把某个商品的单价调高。这是所有人都知道的操作。

第二层：带约束的更新。更新数据前，数据库会检查默认值、非空、唯一性、外键关联。比如在Order Details插入一条明细，数据库会去校验订单头和商品是否存在；删除一个商品，如果还有订单明细引用它，就会被外键约束挡住。

第三层：跨表联动更新。订单明细数量变了，要不要同步改Products表的库存？客户地址变了，历史订单里的收货地址要不要一起改？这类问题没有标准答案，取决于业务规则，但你必须意识到。

第四层：事务和并发下的更新。多人同时下单、同时改库存，怎么保证不会超卖？一条UPDATE语句执行到一半进程崩溃，怎么保证不产生半截数据？这才是数据更新真正的难点。

Northwind最妙的地方，就是这四个层次的问题它都能演示。你可以先手动构造一个外键冲突，再去开一个事务模拟中途失败，最后用多个窗口模拟并发更新。每一步都有直观的反馈，非常适合建立对数据库更新的直觉。

2. 动手前的环境准备与数据体检

2.1 把 Northwind 跑起来

Northwind最初是Access自带的示例库，后来有SQL Server版、MySQL版、PostgreSQL版，现在网上能找到很多社区维护的脚本，下载一个适合你本地数据库的版本导入就行。我自己最常用的方式是直接还原SQL Server的bak文件，然后顺手装一个数据库管理工具。

如果是学习阶段，我建议不要只用图形界面点来点去，尽量用编辑器或查询工具来写SQL。以SQL Server为例，装上之后第一步不是急着执行UPDATE，而是先检查几个和更新行为有关的数据库设置：

SELECT name, is_read_committed_snapshot_on, snapshot_isolation_state FROM sys.databases WHERE name = 'Northwind';

这个查询看的是这个库的隔离级别设置，会直接影响接下来做并发实验时的表现。如果is_read_committed_snapshot_on为0，说明默认的读已提交是加共享锁的，两个窗口同时更新同一行数据时更容易看到阻塞现象。

然后把事务隔离级别也确认一下：

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

MySQL环境的话，注意默认引擎是不是InnoDB。MyISAM不支持事务也不支持行级锁，很多更新实验会得到完全不同的结果，别在这个坑里浪费时间。

2.2 先看清楚数据再动手

我见过太多人写UPDATE不先SELECT一下，把一个表几万行数据全改废了。在Northwind上练手时一定要养成习惯：更新之前，先用SELECT把目标行找出来看清楚。

用Products表举例：

SELECT ProductID, ProductName, UnitPrice, UnitsInStock FROM Products WHERE ProductID = 11;

这句话执行完，你会看到某款产品的当前价格和库存。比如原价是某个数值，库存可能是几十。看清楚之后，再决定要把它改成什么，改完立刻再查一次确认结果。

很多人觉得这一步多余，但在生产环境里，更新之前先查一次，不仅能看到目标数据现在的真实状态，还能顺便确认过滤条件写没写错。条件写错是数据更新事故的头号原因，没有之一。

3. 插入数据：从单行到批量

3.1 插入订单头与订单明细的先后顺序

在Northwind里做插入，第一个练习就是插一笔新订单。订单涉及两张表，Orders和Order Details，它们之间有外键关系，所以插入顺序很关键。

先把订单头插进去：

INSERT INTO Orders ( CustomerID, EmployeeID, OrderDate, RequiredDate, ShippedDate, ShipVia, Freight, ShipName, ShipAddress, ShipCity, ShipCountry ) VALUES ( 'ALFKI', 5, '2024-03-01', '2024-03-08', NULL, 3, 15.00, 'Alfreds Futterkiste', 'Obere Str. 57', 'Berlin', 'Germany' );

如果执行成功，新生成的OrderID可以用下面几种方式拿回来。SQL Server用SCOPE_IDENTITY()，MySQL用LAST_INSERT_ID()，PostgreSQL用RETURNING子句：

SELECT SCOPE_IDENTITY();

拿到新的订单号之后，再往Order Details插明细：

INSERT INTO Order Details (OrderID, ProductID, UnitPrice, Quantity, Discount) VALUES (11078, 11, 21.00, 10, 0);

先插订单头、再插明细，顺序不能反。反了会直接触发外键约束错误，因为明细引用的订单头还不存在。

这里顺便讲一个容易忽略的点：为什么Order Details表要单独存UnitPrice，而不直接去Products表取价格？因为商品价格会调整，历史订单如果引用实时价格，过去的成交记录就被篡改了。这属于典型的快照设计，练手的时候可以在笔记里标注一下，面试时经常问到。

3.2 批量导入时我踩过的坑

单行插入练熟了，自然会碰到批量插入的场景。比如手头有一批商品要录入Northwind，很多人会写一个循环逐条INSERT，结果插了几百条要花很久。正确做法是用批量插入能力。

SQL Server写法：

INSERT INTO Products (ProductName, SupplierID, CategoryID, QuantityPerUnit, UnitPrice, UnitsInStock, Discontinued) VALUES ('Test Product A', 1, 1, '12 bottles', 18.00, 50, 0), ('Test Product B', 1, 1, '24 bottles', 22.00, 30, 0);

MySQL写法基本一样，只需要注意VALUES大小写和末尾分号。批量插入减少的是数据库和客户端之间的交互次数，性能提升非常明显。

但批量插入有个坑：如果你一次插入几千上万行，其中某一行违反约束，整个批次会失败。我在一次导入商品数据时就遇到过，某个分类ID在Categories表不存在，结果整批回滚，最后只能逐行排查。现在我的习惯是：大批量导入之前，先用一条校验SQL把脏数据扫出来，比如查一下要插入的SupplierID或CategoryID是否都存在于主表：

SELECT DISTINCT CategoryID FROM Products WHERE CategoryID NOT IN (SELECT CategoryID FROM Categories);

有返回结果就说明有脏数据，先清理再导入。这一步几十秒的事，却有心思保证整批数据完整性。

3.3 插入时最常见的几个错误

插入数据初学者最容易犯的错误有四类。第一，日期格式写错，直接用'2024-03-01'这种字符串在某些数据库设置下可能被当成年月日之外的解释，最好显式转换；第二，忘记非空字段，Order表里的CustomerID没填就会报错；第三，类型不对，往数值字段塞字符串；第四，违反唯一约束，比如往只允许唯一值的字段反复插同一个值。

这些错误在Northwind上练习时基本都会遇到，建议把错误信息截图或记录下来。数据库返回的错误信息不是废话，它已经把最直接的修复线索给到你了，比如指明了是哪个约束、哪一列出了问题。看多了之后，你逐行排查的耐心就是从这里练出来的。

4. 修改数据：UPDATE 的三个境界

4.1 按主键更新：最安全也最常用

UPDATE最安全的写法是永远用主键来定位目标行。在Northwind里，把订单的发货日期改掉就是一个典型场景：

UPDATE Orders SET ShippedDate = '2024-03-05' WHERE OrderID = 11078;

这句话的意思很清楚：只改这一笔订单。主键在表里唯一，所以这一行就是确定的一行。写UPDATE时，WHERE条件里带主键，就是给自己上了一道保险。

我特别想强调一个判断标准：你写完UPDATE，如果能明确说出它会影响到几行，那说明条件写得很清楚。如果自己都说不准，那别执行，先查清楚再说。SQL Server的OUTPUT子句可以直接看到被改动的行，是一个很好的自查工具：

UPDATE Orders SET ShippedDate = '2024-03-05' OUTPUT inserted.OrderID, inserted.ShippedDate WHERE OrderID = 11078;

这样执行之后，界面会直接把改动后的行返回给你，不需要再单独SELECT一次。MySQL里没有OUTPUT，可以用SELECT受影响行数来判断，或者更新后再查一次。

4.2 多表联查更新：从单表走向业务

单表更新只是热身，真正有意思的是跨表更新。Northwind里最典型的场景是：根据商品分类统一调价。比如“把Categories表里分类名称为’Beverages‘的商品，单价上调10%”。

这个需求不能直接写一条单表UPDATE，因为你不知道哪些商品属于这个分类。先写一个子查询找到这些商品的ProductID，再更新Prices表。在SQL Server里可以用连接更新：

UPDATE p SET p.UnitPrice = p.UnitPrice * 1.1 FROM Products p INNER JOIN Categories c ON p.CategoryID = c.CategoryID WHERE c.CategoryName = 'Beverages';

MySQL的语法略有不同，它允许在UPDATE后直接写多表：

UPDATE Products p INNER JOIN Categories c ON p.CategoryID = c.CategoryID SET p.UnitPrice = p.UnitPrice * 1.1 WHERE c.CategoryName = 'Beverages';

这两条语句干的是同一件事，但语法差异值得注意。如果你在不同数据库之间切换工作，经常会在JOIN UPDATE语法上栽跟头。我的建议是：先用一条SELECT验证范围，再改成UPDATE。比如先执行：

SELECT p.ProductID, p.UnitPrice FROM Products p INNER JOIN Categories c ON p.CategoryID = c.CategoryID WHERE c.CategoryName = 'Beverages';

确认返回的是预期的那几行，再把SELECT部分替换成UPDATE的SET部分。这个习惯能帮你规避大量误操作。调价这种业务操作一旦改错了影响范围，可能直接波及整条产品线。

4.3 更新时要关注的连锁反应

更新单个字段时，数据库只负责改你指定的列，不会帮你处理业务上的连锁反应。举个例子：Orders表里有一笔订单，订单明细中某商品的数量从10改成20，那么订单总金额要不要变？Northwind的Orders表里其实没有存“订单总金额”这个字段，总金额都是根据明细实时算出来的。这是设计上的一种取舍，但如果换成另一个冗余设计，你可能就要手写一段逻辑去同步总金额。

再比如，Order Details的数量改了，要不要同步去更新Products.UnitsInStock？在真实的库存系统里，库存变动往往是独立记录，通过出入库流水来汇总，而不是每次UPDATE明细时直接改库存。Northwind里没有这个流水表，但你完全可以在练习时把它设计出来，模拟一下“下单扣库存、取消退库存”的完整流程。

这类问题没有绝对的对错，但你必须清楚更新一条数据会牵连哪些表、哪条业务规则、哪个统计报表。没有这种全局视野，生产环境里很容易出现“库里数据看起来没问题、业务报表却对不上”的诡异故障。

4.4 UPDATE常见的性能陷阱

Northwind本身数据量不大，性能问题不太明显，但刚好适合演示一个原理：大范围更新会锁住很多行。比如你写一条没有WHERE条件的UPDATE，打算把Products所有商品价格都打八折：

UPDATE Products SET UnitPrice = UnitPrice * 0.8;

在小库里执行很快，但在生产环境的大表上，这条语句会一直持锁直到事务结束，所有想读这张表的业务都会被阻塞，尤其是在默认的READ COMMITTED隔离级别下。

正确的做法是分批更新。按主键范围分批，每次只更新一部分数据：

UPDATE Products SET UnitPrice = UnitPrice * 0.8 WHERE ProductID BETWEEN 1 AND 100;

循环分批执行。这样每批锁定的行数有限，持有锁的时间短，其他业务只需要短暂等待，不至于长时间卡死。在Northwind上练手时，你可以人为加个WAITFOR延迟看效果，虽然数据量小没意义，但能帮你理解锁与批量的关系：

BEGIN TRANSACTION; UPDATE Products SET UnitPrice = UnitPrice * 0.8; WAITFOR DELAY '00:00:10'; ROLLBACK;

开另一个窗口去读Products表，你会发现读也在等待。这就是未提交更新造成的阻塞。在生产环境里，这就是线上事故。

5. 删除数据：容易出事的两类场景

5.1 外键约束下的删除顺序

删除比更新更危险，因为删除是直接的物理清理。在Northwind里，删除订单时如果直接去删Orders表里的一行，大概率会被外键拦住，因为Order Details里有明细引用它。

想删订单，必须先删掉所有关联明细，再删订单头：

DELETE FROM Order Details WHERE OrderID = 11078; DELETE FROM Orders WHERE OrderID = 11078;

顺序又是不能反的。在学习时故意反着执行一次，你会得到一条外键冲突错误，正好直观感受约束的作用。这条约束不是数据库故意刁难，而是它帮你拦下了一个会导致明细变成“孤儿数据”的脏操作。

有人会问：能不能用ON DELETE CASCADE，让数据库自动删关联数据？可以，但要用得非常谨慎。CASCADE把删除行为自动扩展到了子表，后续如果哪天误删父表一行，子表数据也会无声无息被跟着删了，恢复难度成倍增加。我在实际项目中宁可手动维护删除顺序，也不轻易给所有外键加CASCADE。

5.2 用软删除代替物理删除

还有一个思路在业务系统里特别常见：不删数据，只标记删除。在Orders表加一列IsDeleted，默认0，删除时置为1：

UPDATE Orders SET IsDeleted = 1 WHERE OrderID = 11078;

原来的DELETE操作就变成了UPDATE操作，数据还在，只是业务查询里都过滤掉IsDeleted=1的行。这个方案的优点是误删能恢复，审计有据可查，对账方便；缺点是你做SELECT时必须记得过滤，而且历史数据会持续膨胀。

Northwind原始表结构里没有软删除列，但你可以自己加一列练手。加列用ALTER TABLE：

ALTER TABLE Orders ADD IsDeleted BIT NOT NULL DEFAULT 0;

加完之后写查询时，就要在所有业务查询里带上过滤条件：

SELECT * FROM Orders WHERE IsDeleted = 0;

别小看这个练习，软删除和物理删除的取舍，几乎是所有业务系统设计时绕不开的问题。在Northwind上把两条路都走一遍，你对“删除”这个词的理解会比只会敲DELETE的初学者深一个层次。

5.3 清空表时TRUNCATE和DELETE的差异

最后一个删除知识点是TRUNCATE和DELETE的区别。想快速清空一张表，可以写TRUNCATE TABLE Orders，但它不能用于有外键引用的表，而且它不逐行写日志、不触发DELETE触发器，速度极快。DELETE则逐行处理、可以加WHERE、可以被事务回滚。

Northwind里由于表之间外键关系密集，直接用TRUNCATE清订单表会失败。这也算是一个提醒：清空数据之前先理清表之间的依赖关系。如果实在要清空整库，通常要先禁用外键约束或按从子到父的顺序处理。按子表到父表删完所有行再重置自增标识，是常见做法：

DELETE FROM Order Details; DELETE FROM Orders; DBCC CHECKIDENT ('Orders', RESEED, 0);

这一段在SQL Server里执行，MySQL则用TRUNCATE或ALTER TABLE AUTO_INCREMENT=1。操作很简单，但顺序和注意事项比命令本身重要得多。

6. 事务与并发控制：保证更新不出错

6.1 事务保证原子性

数据更新不只有单条SQL，很多时候一个操作要跨多张表。比如创建订单要同时写Orders和Order Details，这两步必须一起成功或一起失败。事务就是干这个的：

BEGIN TRANSACTION; INSERT INTO Orders (CustomerID, EmployeeID, OrderDate, ...) VALUES ('ALFKI', 5, '2024-03-01', ...); DECLARE @NewOrderID INT = SCOPE_IDENTITY(); INSERT INTO Order Details (OrderID, ProductID, UnitPrice, Quantity, Discount) VALUES (@NewOrderID, 11, 21.00, 10, 0); COMMIT;

如果第二条INSERT失败，直接ROLLBACK，订单头和数据头都不会留下。这个机制和“写一半程序崩溃”的情况，数据库都能恢复到事务开始之前。

在Northwind上做这个实验时，你可以故意在第二条语句里写一个不存在的商品ID，让外键失败，再回滚看看结果。你会发现Orders表里并没有多出一笔脏订单。这就是事务的原子性：要么全成功，要么全失败。

6.2 并发更新与锁

事务能防崩溃，但防不了并发冲突。比如两个用户同时把同一件商品库存从100改成98和从100改成95，如果后面的更新直接覆盖前面的，最后库存就是95，实际却卖出去了两笔货，数字对不上。

在Northwind里做并发实验很简单。开两个查询窗口，都执行：

BEGIN TRANSACTION; UPDATE Products SET UnitsInStock = UnitsInStock - 1 WHERE ProductID = 11;

第二个窗口会阻塞，直到第一个窗口提交或回滚。这个阻塞现象就是行级锁在工作，防止两个人同时修改同一行。等第一个窗口执行COMMIT，第二个窗口会立刻继续执行，此时它读到的UnitsInStock已经是被第一个窗口改过的最新值。只要你的UPDATE语句写的是相对增减表达式，而不是固定值，并发下的结果就是正确的。

若写成固定值：

UPDATE Products SET UnitsInStock = 98 WHERE ProductID = 11;

两个并发事务都用旧值做基准，后提交的人就会覆盖先提交的人。这是并发更新中最常见的覆盖丢失问题。在Northwind上分别用“相对增减”和“绝对赋值”两种写法各试几遍，你会对并发问题产生非常直观的感觉。

6.3 乐观锁的一种实际实现

行锁能保证数据库层面的正确性，但业务应用层经常用乐观锁减少锁等待。乐观锁的核心思路是：更新时检查数据是否还是自己当初读到的那一版。

Northwind的表没有版本字段，可以自己加一列RowVersion或VersionNo。以Products为例：

ALTER TABLE Products ADD RowVer ROWVERSION;

有了这个字段之后，每次行只要一被更新，RowVer就会自动变化。应用层更新前先读RowVer，更新时把RowVer作为WHERE条件之一：

UPDATE Products SET UnitPrice = 20 WHERE ProductID = 11 AND RowVer = '某个之前读到的值';

如果影响行数为0，说明别人在你读取之后已经改过这行，需要重新读取并让用户决定怎么处理。这个机制能有效避免覆盖丢失，同时不需要长时间持有数据库锁，适合高并发读多写少的场景。在Northwind上做完一次乐观锁实验，比看十篇文章都管用，因为你已经亲身体会到那行UPDATE返回0行时的紧张感。

7. 常见问题与排查技巧实录

7.1 更新语句卡住不动

新手遇到最频繁的问题是：执行UPDATE后，查询一直转圈，像死了一样。绝大多数情况不是数据库坏了，而是这一行被其他未提交事务锁住了。

排查方法很简单。SQL Server里查正在执行的会话和阻塞源：

SELECT session_id, blocking_session_id, wait_type, wait_time FROM sys.dm_exec_requests WHERE blocking_session_id > 0;

找到阻塞源之后，要么让它提交或回滚，要么用KILL命令结束那个会话。MySQL里查：

SHOW PROCESSLIST;

看到State列是Locked或Waiting for table lock，基本就是锁问题。

在Northwind上练手时，我建议你刻意制造一次锁等待，体验一下排查流程。开一个事务更新Products但一直不提交，在另一个窗口执行同样的更新，然后去查询会话信息，最后提交或回滚第一个事务。这一套流程走下来，以后再遇到线上卡住就不会慌了。

7.2 死锁处理

死锁的场景是A和B互相等对方释放锁。Northwind数据量小，不容易自然触发，但可以用两个表模拟：窗口1更新Products后等窗口2，窗口2更新Categories后等窗口1，最终数据库会检测到死锁并自动杀掉一个事务。

真实系统中，死锁一般通过缩短事务时间、固定更新顺序、建立合适索引来降低发生概率。捕获死锁信息用SQL Server的跟踪标记1222开启死锁图，或者在错误日志里查，方便定位是哪些语句在抢锁。

死锁不是数据库故障，是并发控制中不可避免的一类正常现象。关键是学会读死锁报告，找到是哪几条语句、哪些资源在竞争，然后通过调整事务顺序或减小事务范围来尽量避免。Northwind刚好能用来重复制造这类问题，非常适合做实验。

7.3 外键约束错误

插入订单明细时发现外键冲突，报错信息会提示你哪个字段引用了哪个表。看到这类错误不要急着发懵，先把关联表查一下：

SELECT OrderID FROM Orders WHERE OrderID = 11078; SELECT ProductID FROM Products WHERE ProductID = 11;

哪条查不到，问题就在哪边。多半是订单头还没插入，或者商品ID写错。这个排查套路朴实无华，但非常有效。很多人碰到外键错误就抓瞎，其实数据库已经把方向指得很明确了。

7.4 数据被误更新的恢复思路

误更新真的是所有写SQL的人迟早遇到的事。假设你不小心把Products所有商品的价格都改成同一个值，怎么办？

如果是在事务里执行的，直接ROLLBACK即可。问题在于很多人执行完UPDATE就自动提交了，事务的隔离性这时候帮不了你。救命的办法有两个：一是数据库备份，从备份里恢复那段数据；二是提前预防，对所有重要的更新类型都分类记录日志。

以此为教训，我后来给自己定了一条铁律：生产环境执行的UPDATE，要么先SELECT确认，要么放进事务里先跑再提交，或者经过工具审阅。平时在Northwind上练习，也可以强制自己建一个测试库，用事务包裹所有更新，提交前多看一眼。这个习惯练成本能之后，线上出事故的概率会小非常多。

7.5 快速查询最近更新过的数据

排查问题时经常需要知道“某张表最近哪些行被改过”。Northwind本身没有审计机制，但如果你给表加了RowVersion，就可以根据版本号排序找出最近变更过的行：

SELECT TOP 10 ProductID, ProductName, UnitPrice, RowVer FROM Products ORDER BY RowVer DESC;

Top 10在SQL Server里是写法，MySQL用LIMIT 10。这个思路在生产环境里可以演变成正式的审计日志或CDC机制。先理解原理，再去研究工具，学起来会快很多。

8. 几点个人经验

Northwind这个库我前前后后带人用了几十次，几乎每次都会在数据更新这个主题上发现新的教学点。我自己最大的感受是：不要一上来就抓着高级语法学，先把“改数据”这件事背后的约束、事务、锁、回滚这些底层机制亲手摸一遍，比背一百条SQL技巧都管用。

一个很推荐的练法是：给自己布置一个稍微完整的业务任务，比如实现一个“订单修改”功能，要求支持改明细数量、重新计算总价、记录库存变动。你会在实现过程中遇到外键、并发、快照、事务等一系列问题，全部解决下来，你对数据更新的理解会有一个质变。Northwind提供了全部素材，你需要做的就是动手。