天天鼓捣数据，揭秘数据库的神秘面纱

来人人都是产品经理【起点学院】，BAT实战派产品总监手把手系统带你学产品、学运营。

是的，你没有看错，不是发重了，本文就是大前天的文章《天天捣鼓数据，你知道数据库长啥样？》的续篇。这几天有些同学在后台留言表示想进一步了解数据库的相关技术，确实之前的文章限于篇幅，只介绍了一些基本的概念，今天我们来把剩下的东西补一补。

现在，我假设你已经被我成功灌输了 「数据库就是一个大文件，里面有很多表，每个表就像Excel一样，存储了若干条记录」这样的概念。但是，过年回家长辈问你什么是数据库，光这样是拿不到红包的，所以我们继续来深入探讨一下下面几个问题。

什么样的数据适合用数据库来存？

结构化的数据。有的数据，天生就有很好的结构，比如要记录一个人，我们会这样描述：罗玉凤，女，1985年9月生，重庆市綦江区人。要记录一部电影，这样描述：《星球大战》，导演乔治卢卡斯，科幻片。这样记录数据最大的好处是方便查询，你要查凤姐的身高，输入「凤姐，身高」两个关键字就可以了。非结构化的数据，比如苍老师.avi、小苹果.mp3这些，就不适合用数据库来存。你拍了一张凤姐的照片准备存起来，先不说能不能放到数据库里，你要让计算机根据一张图片来得出凤姐身高这样的查询结果，目前的科技水平还是很难做到。那非结构化的数据怎么存呢？我上传了一张个人头像到微信上，微信的服务器就会把这个头像的图片文件存到服务器的硬盘上，然后把文件路径存在数据库里。这时候你再去请求这张头像，输入微信id，头像这样的关键词，微信就会先去数据库查你的头像文件对应的路径，然后根据路径在硬盘上找到文件回给你。

如何来设计一个数据库？

什么？数据库还需要设计？别慌，先来看个例子。你公司的程序员终于忍受不了产品经理无节制的加需求，愤而离职，留下一个朋友圈消息后台需要你亲自上阵。用户编辑完要发的消息之后，会发送到你这里，你需要把这些消息完整的存到数据库。每一条消息是这样的：

拿到这样的数据之后，你应该如何设计一张数据表的结构呢？前面讲过，表是由行和列组成的，每一列表示一个属性，每一行表示一条信息。这个跟Excel对比起来很容易理解，每一列的属性确定了之后就不变了，以后每来一条数据，就添加一行。

这样就可以满足我们的需求了。但是，等数据量大了之后，我们就会发现这个表是有缺陷的。首先是数据冗余，每次李小花同学发表一条消息，就会把他的昵称、性别、姓名重复插入到我们的表中。其次，如果在未来的某一天，李小花改了她的昵称，那么我们要遍历整张表去更新她的昵称(可能现在已经有上亿条消息了），这也是不现实的。所以这里需要把表拆成user表和message表。拆表之后，通过姓名李小花既可以查到她的个人信息，又可以查到她发的所有消息。

这样就可以完美解决上面的两个问题了。这个过程叫规范化，就是说数据库的设计是有一些规范的，这些规范经过了严格的数学证明，你一定要遵守。

就差一个码代码的了。

之前的文章介绍了SQL语言，它是专门用来操作数据库的。编程语言你可以理解为是一些命令串起来，每一条命令都可以让系统实现一种功能。上面的两张表，我们这样来创建：

create_table user(姓名 varchar(20),昵称 varchar(20),性别 varchar(10));

create_table message(姓名 varchar(20),时间 datetime,message text);

对表本身的操作除了创建，还有drop(删除)、alter(更改属性)等等。

当有用户新发表了一条消息，我们可以这样插入到表中：

insert into message values('李小花'，now,'I am very OK!');

当客户端来了请求，要查询王小龙同学的所有消息的时候，可以这样:

select * from message where 姓名='王小龙';

对表内数据的操作还有delete(删除)、update(更改)等，当然最精髓的还是查询select了。我们浏览贴吧看帖子，上微薄看热门都是执行的select命令，这个命令的执行速度直接影响到用户的体验，所以程序员必须优化好。

数据库这块儿的东西先讲到这里，一些代码大家看不懂没关系，如果以后用的上，知道是怎么回事儿再去查就能学的很快。但是，即使知识get到了也千万不要去程序员那儿秀技术，程序员都觉得自己技术最牛b，你就让他继续牛b下去，对产品经理也没啥坏处，哈哈。