数据库表设计毫无头绪？三步完成数据库表搭建

我的开发生涯里，百分之80%的项目都是需要使用到数据库的，所以每次进行新项目的搭建都要根据项目需求，设计与之对应的数据库表来承载项目的运行。我都会通过三个步骤完成数据库的搭建。

写在数据库搭建之前

我先明确我设计数据库的目的。我主要是为了解决以下四个问题：

A）解决大量数据存储问题。即如何才能将数据完整的而不混乱的存储数据。

B）解决解决数据共享问题。比如数据库中，一条包含商品基本信息的记录，app端展示要用，小  程序端展示也要用，商户管理端要对这条数据做增删改操作等场景下，数据如何能够适应它们 其中一端的使用而不导致其他端的崩溃等问题。

C）简化数据维护的成本。比如我们常见的商品表，这一张表中就包含了商品的所有的信息字段。  现有一个业务流程中需要你仅查询出商品的名称，价格和简要描述。但因为所有信息都在一张表中，把封面，规格等暂时不需要的数据都查询了出来，查询时间无疑会对用户体验造成影响。若要对商品其中某一参数进行更新，又保持其他参数不变，这维护数据的复杂度也增加了。这些维护成本是可以通过分表，优化数据字段等操作来降低的。

D）解决数据安全问题。哪些角色可以有权限看哪些数据是很重要的，不然很容易造成数据泄露，导致整个项目产生信息安全问题。

第一步：查看需求文档，统计项目有哪些功能，推导出数据库表

在企业做项目，公司会安排专门的人去和客户对接并生成需求文档，会明确细分有哪些功能模块，每个功能模块有哪些功能。当然也有很多刚成立不久的企业，部门还没有那么健全，自己上手去和客户统计需求的事也是屡见不鲜。

无论如何，都要先了解整个项目是做什么的。要有哪些功能。

只有对整个项目掌握了，才能设计出适合这个项目的数据库。

看上图中的思维导图，就能很轻易的得出有哪些表

要采集用户信息----用户表

有案例----案例表

 有专题---专题表

有轮播---轮播表.........

除了这些能看出来的，有些表则比较难得出，需要做多做项目才能熟练。比如，

角色表，权限表，管理员表，登陆日志表.....

不过这些问题也不大，这些表都有行业内的大佬提供了通用的解决方案。刚开始设计数据库时，必不可少的要去多看多学，涨见识。

总结：分析项目的需求，需要哪些功能完成，从而得出有哪些表。

第二步：确定每张表的字段，以及表与表之间的关系

• 如何确定每张表要有哪些字段？

提示：要做好这一步，必须对数据库的基本知识熟练掌握。比如什么是唯一性，数据库设计三大范式，表与表之间一对多关系，多对一关系，什么是数据冗余，主键，外键，什么是中间表等知识。

使用类比法，把一张表看成一个对象，描述这个对象的属性。而这个属性就是字段，项目中需要多少属性才能描述清楚一个对象就有多少字段。与我们语文作文类似。

直接上实操,我要描述一个用户如下：

性名：xxx

性别：男

电话：182xxxxxx92

email：xxxxx@qq.com

账号：xxxx

密码：xxxxx

地址：xxxxx

上次登陆时间：xxx/xx/xx    xx:xx:xx

账号状态：正常

.........

 根据上面的分析可以确定：

用户表的字段，用表格表示出来：

用户表：

id	nick_name	sex	phone	email	user_name	pass_word	address	status
1	xxx	1	182xxxxxx92	xxxxx@qq.com	xxxx	xxxxx	xxxxx	1

当然用户表字段的多少是与业务相关的，如果还需要看用户何时注册等信息，create_time字段也是要有的。头像（avatar）这些，只要用得上也都可以加上去。

特别提醒：字段需要避免关键字；尽量用英文，不要用拼音；字段类型，尽量对应，避免都使用String类型；

•  如何确定表与表之间的关系？

表与表之间就三种关系：

 一对多：最常用的关系，在多的一方放外键字段

多对多：有中间表

 一对一：相对使用比较少

特别提示：要避免数据冗余。当然不是绝对，如果为了提升性能可以适当的冗余。

遵守三大范式，设计出的数据库，bug率能有效降低

 第三步：使用SQL语句或数据库工具，完成数据库的创建

我推荐使用sql语句完成数据库的创建

使用SQL的好处：

• 相较于使用工具，使用SQL创建，只要语句是正确的，出现失误操作的概率低。
• 能加深对SQL的掌握程度。熟能生巧就是这个意思，这个过程还有利对SQL的理解。

数据库管理工具推荐：

• Navicat Premium 是一套可创建多个连接的数据库管理工具，用以方便管理 MySQL、Oracle、PostgreSQL、SQLite、SQL Server、MariaDB 和 MongoDB 等不同类型的数据库

结语：设计数据库不难，只要知识储备足够，方法得当，设计数据库于吃饭一样可以轻松拿捏。