本帖最后由 dirtwillfly 于 2018-7-24 20:08 编辑
各位大咖大家好，新人报道，发个帖子望各位不吝赐教！
前言目的：这篇**旨在带领准备入门的朋友对基本的数据库知识、数据表逻辑设计、mysql数据库有一个基本了解，以便快速上手实际业务。 数据库漫游从一个实例出发比如将一堆数据存储在一个文件中（比如每个人的年龄），假如数据很少，那么光是人眼看就可以轻松的找到某一条数据。但是当一个文件存储的数据很多的时候，这时候人眼根本找不过来，并且这个文件也因为体积过大而打开速度及其慢。怎么办呢？ 拆分。将数据分别存储在多个文件中，规定每个文件只能存100条数据，然后文件名按照所存储的年龄段命名。这时想要查找某一条数据，人眼就可以选择对应的文件从中筛选出目标数据。假如又要存储每个国家的位置该怎么办呢？ 分别存储。人的年龄数据和每个国家的位置信息我们都分别存储到不同的文件中。所以，现在我们电脑上的文件们就如下图所示：
我们现在有两个文件组，一组文件存储的是人的年龄，一组文件存储的是国家位置信息。这时，我们想要查找某个国家的位置，我们就从文件1和文件2中查找信息，当然，我们也可以做一些优化，比如规定亚洲非洲的国家存储在文件1中，其他国家存储在文件2中，这样子就可以少查找一个文件，减轻眼睛的负担。 现在问题又来了，假如我们要存储全球每个人的年龄怎么办？文件数目会呈现几何增长，就算是20岁这个年龄段都会有成千上万的文件，我们人眼怎么找的过来呢？当然，我们可以手动做一堆优化，但是边存储边优化会把人累死，完了还要再查找。所以我们开发了一款管理软件，我们只要按照一定规定告诉他存储什么，然后告诉他我们要查找什么，这样子就方便了，就可以做到自动化。 所以，我们这一套存储系统可以分成两大块，如下图所示： 底层的存储配合上层的管理形成一个完整的数据管理系统。这套系统解放了我们的生产力，并且由于公司中有很多部门都共用这套系统，所以我们对其进行了更多的优化，具体如下： l 公司中每个部门都可以新建一个文件夹，用于数据存储 l 每个文件夹中可以创建不同的文件组，每个文件组内保存的数据结构都是一样的，比如用户信息文件组只能保存用户信息，而不能保存国家信息。文件组中是一个个的文件，这些文件如何拆分不需要使用者考虑，使用者只需要选择好文件组，输入需要存储的数据，然后点击存储即可。查询时，使用者只需要告诉系统去哪个文件组中查询什么数据即可，比如查询中国的位置信息。 l 对于公司中的一些极客，他们不想在管理系统界面上点击，而是向通过指令去实现操作，因为这样看起来更酷。所以我们又设计了一组指令，比如当极客们在系统上输入“select age from 文件组1 where name = geek ”这样的指令时(当然前提他得选择自己的部门，也就是先选择好是哪个文件夹)，系统就会解析这条指令，系统读到select 就知道极客想做的操作是查询数据，读到age 知道是要查询年龄这个数据，读到“from 文件组1 ”就知道要去文件组1中去查找年龄，读到“where name = geek ”就知道要查找的条件是什么，那么综合看起来就是要查找姓名是geek这个人的年龄信息。 好了，以上基本就把和数据库相关的点介绍了一遍，现在来和常见的mysql数据库管理系统做一个对比： 可以看出，mysql实际应该叫做数据库管理系统，对标我们设计的管理系统。mysql具体也分为上层管理模块和底层存储模块。我们为每个项目在mysql中创建一个数据库，然后设计数据表结构（存储什么数据，比如年龄、时间、姓名等这种），之后就可以通过指令来告诉mysql存储获取读取什么数据了。mysql本身也对存储等做了许多的优化，就类似我们上面提到的。 进一步认知我们可以将mysql和Excel这款软件做一个类比。Excel大家都很熟悉，创建一个excel文件后，excel文件中还包括sheet1、sheet2这种子表格。我们可以把每个excel文件当作一个数据库，把每个sheet当作一个数据表，然后每个sheet中可以自定义表格的各项列名，之后既可以往表格中填充数据了。这样子是不是形象了很多？ 数据库分类数据库主要可分为两类：关系型数据库和非关系型数据库，除此之外还有时序数据库等其他小众一点的数据库。关系和非关系型数据库的区别主要在于底层存储结构的不同。 mysql属于关系型数据库，每一张表都可以看作是一个“关系”，也即底层存储结构是关系表这种结构，算作是数学上的概念，我也没深入了解过。各位可以自行深入研究。 比如mongoDB就属于非关系型数据库（NoSQL），他的底层存储结构就是另外一种JSON格式的文档，所以也叫做文档型数据库。 这一块知识目前作为了解即可，有兴趣请自行搜索。 数据表逻辑设计漫游经过上面的介绍，我们知道在存储数据之前，需要设计好表的结构，比如存储什么类型的信息等等，那么如何设计呢？开发中我们需要遵守一些约定。 往下走之前，需要先有基本的认知：比如下面的用户信息表格： 这张表格中，每一行都对应一个用户的信息，然后这个表格有四个字段（列名），每个字段都表示用户的一个属性。这样能理解就可以了。 现在有一个场景：有几对夫妻，每对都是夫妻二人共同购买了一间房子，也共同购买了两辆以上的车。现在要存储每个人的信息，房子信息，车信息，如何存储呢？ 首先建立人的信息表，具体如下： 然后建立房子的信息表： 最后建立车的信息表： 好了，第一步就建立好了，可以看出每张表都是一个独立的表格，人的信息表只存储人的数据，车的信息表只存储车的数据。假设我们已经往里面填充了一些数据，那么现在有个问题：我现在拥有C这个人的身份*号信息，那么我如何查找C拥有的车的信息呢？ 答：无法查找。 这答案显而易见，上面三个表格之间根本没有任何关联关系，彼此都是相互独立的，那么我怎么可能根据人的某项信息来找到他下面的车呢？看来我们的表的存储结构设计的有待完善。 既然人、车、房之间在现实中本来就有关联关系，那么我们设计的表格中也应该有关联关系才对。经过分析，我们可以发现，每个人都只有一间房子，而一间房子反过来又和多个人（这里是夫妻二人）有关系；每个人都有多辆车，而每辆车又属于多个人（这里是同属于夫妻二人）。这些就是他们之间的关系。 所以我们的改进如下： l 房子和人之间是一对多的关系：一个人只有一套房子，一个房子对应夫妻两个人。所以我们在人的数据表中加入一列，表格如下： l 人和车之间是多对多的关系：一个人拥有好几辆车，每辆车又会对应两个人（夫妻二人）。面对多对多的这种关系，我们提取出一张中间表，而不再对人的表和车的表进行修改： 可以看出，这张表就通过身份*号和车牌号建立了人和车之间的关联关系。 l 车和房子之间没有直接的联系，所以不再进行处理 好了，现在我们根据一个人的身份*号来查询这个人下面的房子信息怎么查询呢？ 答：直接根据身份*号在人的信息表中找到一行（也即这个人），然后就可以看到这行数据中的房子地址了，我们拿到房子地址后就可以根据地址去房子的数据表中查找该房子的具体信息了。 那么，如何根据身份*号查询车的信息呢？ 答：我们去人-车关联表中查找到这个身份*号对应的几个车牌号，然后就可以根据这几个车牌号去车的数据表中查询有关的数据信息了。 数据表设计规则总结数据库设计是有几大范式的，但是他们都比较高深莫测，实际开发中我们遵循下面的规则即可： 1. 每张表只存储一类数据，比如用户表就存储用户信息；（做关联用的列不算，比如上面例子中人的表中还存储了房子的地址，但是地址是做关联用的） 2. 设计表之前首先要划分清楚各模块是什么，比如用户模块、车、房子，然后理清楚各模块间的关系，两张表之间如果存在关联关系，则该关系可以分为三种：一对一，一对多，多对多。 3. 分别先独立的设计各个表的结构，这样设计完后是一张张相互独立没有关联的表 4. 然后按照两表之间的关系来进行完善即可。
那么两表之间的关系如何完善呢？ l A和B之间是1对1关系，则将一张表的唯一字段（唯一能够确定一行数据的）放入另外一张表中：比如用户表和手机表是1对1的关系，那么我们可以将用户身份*号放入手机表中，作为手机表的列名（字段）之一。 l A和B之间是1对多关系，则将“一”这一端的唯一字段放入“多“的一端中：比如用户表和衣服表，一个用户有多件衣服，一件衣服只属于一个用户，那么就将身份*号放入衣服表中即可 l A和B之间是多对多 关系，则建立一张中间表，把AB两表中的唯一键放入中间表即可：比如手机表和APP表，一个手机可以安装多个APP，一个APP可以被多个手机安装。那么我们将APP的ID号和手机的手机号一同放入一张中间表（也叫关联表）中即可。 遵照上面的规则去设计数据库中的数据表就没有什么问题了。
| 
楼主
标题置顶
标题高亮
