数据库方面的面试技巧，如何从建表方面展现本身能力

时间 2019-11-30

标签数据库方面面试技巧如何展现本身能力栏目 SQL 繁體版

原文原文链接

在面试java web方面的高级程序员时，我必定会问到 jave core，java web（好比Spring MVC，Hibernate等）和数据库相关问题。在数据库方面，对于java 高级程序员而言，不只须要会基本的增删改查，并且须要具有必定的“优化”方面的技能。java

优化是个大话题，能够从索引，建表和SQL 调优（SQL Tuning）方面入手，这个咱们来分析下建表时须要注意的优化点。程序员

我通常会问候选人，“你有没有设计过数据表？”，大多数回答是设计过，接着我会比较阴险地问下：“你在设计表时是否用到了三泛式”？web

不少计算机专业的候选人每每会随口回答“是”。这时我就不细问了，同时给候选人写下以下的评语，“该候选人有基本的数据库操做的技能，会增删改查操做，但缺少专业的数据表设计的能力”。面试

好了，先来看下三泛式的概念：在第三范式里， 数据不能存在传递关系。数据库

好比有张订单流水表，其中包括（订单编号，商品编号，下订单的会员编号，商品名，商品价格，会员姓名，会员手机，会员地址）这些信息。性能

在这个表里，就存在两个个传递关系。从商品编号能看到商品价格商品名等信息，从下订单的会员编号能看到会员姓名，手机和地址的信息，因此不符合三泛式。优化

若是要按经典学院派的三泛式，咱们得把这个表拆分红以下3个表。网站

订单流水表spa	至少包含订单编号、商品编号和下订单的会员编号设计	假设过去1个月有100万条
商品表	至少包含商品编号和商品名	假设过去一个月有50万条商品信息
会员表	至少包含会员编号会员手机会员地址	假设过去一个月里有10万名会员下过订单

先说下这样拆分的好处（也就是三泛式）的好处，那就是没数据冗余，假设以前的订单流水表包括（订单编号，商品编号，下订单的会员编号，商品名，商品价格，会员姓名，会员手机，会员地址），而与此同时，必定也有张商品表和会员表，这样“商品名“就冗余了（出如今订单流水表和商品表里），“会员姓名“等字段也冗余了（同时也出如今会员表里）。

这样作，万一咱们得修改会员手机，那么就获得两个表里同时修改，增长了工做量不算，并且还增长了出错的风险（万一哪一个表忘记修改了，数据会不一致）。

看上去三泛式很美，可是（不少事情就坏在可是以后），万一在一个大型系统里（好比某宝），数据量很大，就如按上表给出的数据量。那么若是我要执行一个很是基本的需求，要列出过去一个月里全部买过Java书籍的会员的邮箱，以便咱们发些推荐邮件。

这句SQL语句不复杂，但关键是得“关联”，咱们能够用订单流水表 left join商品表 on 订单流水表的商品编号 = 商品表的商品编号，在left join 会员表 on 订单流水表的会员编号 = 会员表的会员编号。

关联是要代价的，这里咱们就得作三张大表之间作关联，哪怕我再作优化，再利用到数据库系统的优化（好比用尽Oracle里的优化配置），但因为三个表比较大，关联的样本就大了。

这时，若是咱们来看下“比较丑”的作法，就一开始把全部字段写到一个表里。

订单流水表 =（订单编号，商品编号，下订单的会员编号，商品名，商品价格，会员姓名，会员手机，会员地址）

那么因为不须要关联，性能就很显著提高。

从这个案例中，你们必定能看到，若是某候选人告诉我设计表时都得遵循三泛式，那么我给出的“没设计过数据表”也没冤枉他。

那么关于设计数据表方面，你们该怎么展现本身的能力呢？分类讨论。

第一，若是在设计的时候，已经明确地知道这个系统的数据量不会太大，好比一个中学的图书管理系统，最多有5万条书本的数据，过去一个月里借阅记录不会超过1千条。也就是说，表之间的关联代价不会过高，那么用“三范式”的原则是必需的。毕竟三范式能避免数据冗余带来的更新插入上的“须要同时多表里相同字段”的麻烦。

第二，若是表的数据量很大，如前面举的在线购物网站的例子，咱们可能就须要冗余数据。在订单流水表里，同时放入用户邮件地址和商品名的字段。

在获得“免去链接操做”的好处同时，也得付出相应的代价，好比用户一旦更新了邮件地址，那么咱们就须要同时在会员表和订单流水表里修改该字段，这就是冗余带来的后果。

也就是说，我在询问如何设计数据表时，我不在意你以前设计过哪些表？关键看你在设计表的时候须要考虑哪些因素。

你们不只须要掌握诸如“链接”和“范式”之类的技术，更应该从业务角度，权衡各类“建表代价”，从而挑选一种最符合本项目的解决方案。

好了，关于建表方面的技能就说到这里，很简单，你们一两分钟就能看完，但若是你不会说，或者没说到“权衡”，那么对不起里，即便你有过建表经验，那么在面试中你没表现出来，我只能认为你不熟悉这块。