为什么一张表格不够用
假设你经营一家漫画租借店。你需要会员名册，需要在库漫画清单，还需要谁在什么时候借了什么、什么时候还的记录。
这些能全塞进一张表格吗？硬塞是能塞，但很快就没法用了。左边一块放会员、中间放书、往下从某一行开始放借阅记录，这样是管不下去的。
所以要拆成多张表。会员放会员表，书放书表，借阅记录放另一张表，然后把它们连起来。「这位会员借了这本书」这件事，写成连接两张表的形式。
关系型数据库正是这个形状。名字里的「关系」指的就是这些连接。
表、行、列，以及键
一张表叫 table，相当于电子表格里的一张工作表。
最上面一行放列名：编号、姓名、联系方式之类。下面每一行堆一条数据。一位会员一行，一本书一行。
接下来是连接。假设会员表里某位会员的编号是 1。在借阅记录表上设一个会员编号列，在那里写 1，就表达了这条借阅属于这位会员。这种指向别的表的值叫外键。
还需要一个能唯一标识每一行的值，比如会员表的编号，永不重复。这叫主键。外键归根结底指向的就是另一张表的主键。
members books loans
───────────── ───────────── ──────────────────────
id name id title id member_id book_id
1 金敏秀 7 灌篮高手 1 1 1 7
2 李书妍 8 灌篮高手 2 2 1 8
3 2 7
loans.member_id 是指向 members.id 的外键
loans.book_id 是指向 books.id 的外键模式很死板，也正因此稳定
表的形状叫模式：有哪些列、每一列能放什么形态的值，都事先定好。
定得相当细。这一列只能放数字，那一列文字最多多少个字，这个值不能为空，那个值之间不能重复。
它死板。以后要加一列或改形态，就得处理已经存进去的数据。作为交换，它稳定：不合规定形态的值一开始就进不来。
所以「一份数据该拆成几张表、怎么连」本身就是一门专业。服务做大了，会有人专职负责这份设计。同样的数据，拆法不同，后面是扛得住还是扛不住就分岔了。
查询，以及非关系型的那些
让数据库做事的语句叫查询。取值、写入、修改、删除都靠这些语句下达。
名字里带 SQL 的产品全都说这套语句。PostgreSQL 就是其中之一，在氛围编程项目里经常遇到。语句长相大体相似，学会一种在别的产品上也通用。
如今直接在代码里写查询的情况少了。中间替你生成查询的工具已经很成熟，在上一篇讲的后端代码里把数据形态定义好，查询就由它来写。
也有非关系型的种类。把每一项整个当作一份文档来存的文档型，适合形态经常变的数据。只存「什么与什么相连」的图型也有。不过网页服务的默认依然是关系型。下一篇看不放进这些表里的东西，图片和视频放在哪里。
SELECT title FROM books WHERE id = 7;
INSERT INTO loans (member_id, book_id) VALUES (1, 7);
UPDATE members SET name = '金敏秀' WHERE id = 1;
DELETE FROM loans WHERE id = 3;