说说怎么用简单话讲清楚数据库里那些实体和它们的结构到底是啥样的

整理自知乎用户“西门吹雪”的高赞回答、B站UP主“程序员鱼皮”的科普视频以及《SQL必知必会》一书中的核心思想,用最生活化的方式重新演绎）

咱们就拿开一个小卖部来打比方,你就全明白了。

数据库就是你的小卖部仓库

你得有个地方放货，对吧？这个放所有商品的大仓库，就是数据库，它就是一个实实在在的、用来存东西的“地方”，你不可能把辣条和文具都扔在露天广场上，那样就全乱了，也容易丢，数据库就是这个安全的、有屋顶有围墙的仓库。

数据表就是仓库里的货架

你进了仓库，肯定不会把所有东西胡乱堆在一起，你会分门别类：这一排货架专门放零食，那一排货架专门放文具，角落里可能还有个冰柜放饮料。

数据库里的数据表，就是这些货架，一张表专门存一类信息，你可以有一张叫“商品信息”的表，就像你的零食货架，上面只记录所有零食的名字、价格、生产日期这些信息，另一张叫“顾客信息”的表，就像你的会员登记本，只记录所有来买东西的顾客叫啥、电话多少。

表的每一行就是一件具体的商品

我们走到“零食”这个货架前，货架上是不是一格一格的？每一格里放着一件具体的商品，第一格是“XX牌辣条”，第二格是“YY牌薯片”。

在“商品信息”这张表里，每一行就对应着货架上的一件具体商品，第一行是辣条的所有信息，第二行是薯片的所有信息，这个“行”，在专业术语里叫记录，你就记住，一行就是一条具体的记录，张三”这个顾客是一条记录，“李四”是另一条记录。

表的每一列就是商品的一个共同特征

你再仔细看货架上的商品，虽然每一格里的商品不同，但它们都有一些共同的特征标签，每一件商品下面是不是都有个小标签，写着“商品名称”、“价格”、“产地”？

在表里，每一列就是这样一个共同的特征，商品名称”这一列，从上到下就写着：辣条、薯片、可乐……“价格”这一列，就写着：2.5元、5元、3元……这个“列”，在专业术语里叫字段，你就记住，一列就是一个属性,一个大家都有的信息项。

主键就是商品的唯一“身份证号”

想象一下，如果你的小卖部进了10包一模一样的辣条，它们名字一样、价格一样，你怎么区分哪一包是先进的？哪一包是后进的？万一有一包过期了,你怎么精准地把它找出来扔掉？

聪明的话，你可能会给每一包辣条贴上一个独一无二的条形码或者编号，辣条-001”、“辣条-002”……这个编号就是这包辣条的唯一身份证,绝对不会重复。

在数据库表里，这个“身份证”就是主键，我们会给每一行数据都设一个唯一的、不重复的ID，比如在“顾客信息”表里，除了姓名、电话，我们再加一列叫“顾客ID”，这样，就算有两个都叫“张三”的人来买东西，我们也能通过“顾客ID：1001”和“顾客ID：1002”把他们区分开，绝对不会搞混，主键是这条记录的唯一标识,是最重要的东西。

表与表之间的关系就像“小票”把商品和顾客连起来

有个叫李四的顾客来买东西，他买了一包辣条、一瓶可乐，你怎么记住这笔交易呢？你肯定会开一张小票，对吧？小票上会写：小票号888，日期，顾客李四,然后下面列出他买的辣条和可乐。

在数据库里,这事儿就需要多张表来协作：

• 顾客信息表：存着李四的基本信息（ID，姓名……）。
• 商品信息表：存着辣条、可乐的基本信息（ID，名称，价格……）。
• 订单表（就是那张小票）：这张表很关键，它就像一座桥梁，它里面会有这些列：“订单ID”（小票号）、“顾客ID”（指向是哪个顾客买的）、“商品ID”（指向买了哪个商品）、“购买数量”等。

你看，通过“订单表”里的“顾客ID”和“商品ID”，我们就成功地把“顾客”和“商品”这两件本来不相关的事情联系起来了，这就叫表关系，这种关系让你能查到“李四买了什么”，也能反过来查“辣条都被谁买过”。

数据库结构就是这么回事：

• 数据库 = 大仓库
• 数据表 = 仓库里的一个个货架（按类别分）
• 行（记录） = 货架上的一件具体商品
• 列（字段） = 商品的一个共同特征（如名称、价格）
• 主键 = 商品独一无二的身份证号
• 表关系 = 用小票（订单表）把顾客和商品联系起来的方法

这样一来，你小卖部所有的进货、销售、顾客信息都安排得明明白白，井井有条，你想查什么，这个月哪种零食卖得最好？”或者“老顾客王五总共消费了多少钱？”，数据库就能像你最得力的仓库管理员一样，立刻给你把答案找出来，它的所有结构设计，最终目的就是为了有条理地存东西，然后又快又准地取东西。