过一段时间回看之前项目的数据库设计都忍不住吐槽,这谁写的(我自己),当然也说明自己进步了哈。
本篇主要从性能和编码方便的角度来看中间表的使用。
昨天看原来写的数据库就发现了问题!背单词app,单词书和单词要联系起来,两种方案:
- 单词书表里面包含单词,重复的单词书记录跟着不同单词,如图。
这样的问题是单词书表数据量太大太冗余,我们在查单词书的时候很不方便效率也很低。而且单词表存在的意义好像不大,肯定是不满足第三范式了!
- 加入中间表book_word,单词书表和单词表不变,上图展示的表作为中间表!!!值得推荐,我们在查该学这本书的第几个单词的时候很方便,不用表连接,单表查询!不好的地方是数据冗余,不满足第三范式!是一种空间换时间的方式。而且修改单词书或单词信息的时候中间表也要记得改。
- 对中间表进行修改!单词书信息和单词信息都只保留id!好处是满足第三范式,不足之处是查询起来不方便还需要连表查询,不过修改单词书和单词信息的时候不需要修改中间表。
- 另一种对中间表修改折中的办法是单词书信息只保留id,单词信息是完整单词信息,同样是不满足第三范式,但是针对场景我们需要的是根据书籍id查单词信息,这样更符合场景。
总结
中间表使用必要很大,但是如果去满足第三范式,编码不方便需要连表查询,针对场景数据冗余一点个人认为是有必要的,主要是一个表只有三个id字段感觉很怪,太浪费了。
mysql 中间表 性能_mysql性能优化