数据库方面的面试技巧，如何从建表方面展示自己能力

最新推荐文章于 2025-03-31 13:30:32 发布

原创最新推荐文章于 2025-03-31 13:30:32 发布 · 929 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #面试 #职场和发展

程序员专栏收录该内容

238 篇文章

订阅专栏

文章探讨了在数据库设计中遵循第三范式（消除数据冗余）的优点和挑战，特别是在大型系统中的关联查询性能问题。同时提到了在大数据场景下，如Kafka架构的使用和面试准备的重要性，分享了Java开发的学习资源包，旨在帮助工程师提升技能并降低学习成本。

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

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

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

如果要按经典学院派的三泛式，我们得把这个表拆分成如下3个表。

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

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

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

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

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

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

这时，如果我们来看下“比较丑”的做法，就一开始把所有字段写到一个表里。

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

那么由于不需要关联，性能就很显著提升。

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

那么关于设计数据表方面，大家该怎么展示自己的能力呢？分类讨论。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。