数据驱动生活,你了解数据库的真面目吗?

发表时间: 2016-01-22 14:35

来人人都是产品经理【起点学院】,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下去,对产品经理也没啥坏处,哈哈。