up:: SpringBoot电商项目开发所需工具IDEA插件
说明：
（1） 数据库表设计是一项很重要的能力；但是，这种能力又不是一朝一夕就能很强的；需要自己不断的总结、归纳、对比，慢慢提升；
（2） 前面几个项目中，遇到的数据库表设计有：
● 【开发基于RBAC的权限控制模块】：这个表设计的核心就是，RBAC角色控制的OA系统的业务场景下的表设计；
●【建表前的分析】：这个表设计不太复杂，其主要就是有【会员表】和【图书表】，以及基于这两张表衍生出来的【图书评价】、【图书分类】、【会员阅读状态】表；
● 本项目的表设计，可以结合上面提到的两个项目的表设计，对比着看一下；（PS：也没必要过分研究，能懂）
（3） 对于一个项目，设计数据表是需要一定的能力的；而且，我们设计数据表的时，也不是一蹴而就的；可能，我们一开始没有考虑全面，后续随着业务的发展，发现需要新增、更改、删除字段的话，是可以随时修正的；
表设计：分析项目中需要的数据表，包括表名、表中的字段、字段的类型、注释、字段特征等进行分析；
0.创建一数据库逻辑空间，并通过SQL文件，创建我们需要的表；
说明：
（1） 记得逻辑空间的字符集要选择utf8mb4；
（2） 项目提供了SQL脚本，可以快速创建数据表；
1.imooc_mall_user用户表；
说明：
（1） 这个表以user结尾，很容易知道这个表就是用户表；但是，虽然这个表里面会存放多个user，但是这个表的命并不是imooc_mal_users；
● 根据表设计规范，数据库的表名不使用复数；
（2） 表需要加上前缀，比如这儿的【imooc_mal_user】红色部分就是公共前缀；
● 在大团队中，经常会有不同的项目去公用同一个数据库；那么，此时，这儿的表就会很多；不仅仅有imooc_mall慕慕商城项目的表，还可能有qiqi_mall琪琪商城项目的表；那么，这两个项目是可能有相同或类似功能的表的，比如都有order订单表；那么如果加上前缀，慕慕商城的order表是imooc_mall_order，琪琪商城的order表是qiqi_mall_order表；这样，也好区分；
● 给数据表加上前缀，也可以很好的防止与关键字冲突；；比如order、user这些都是MySQL的关键字，而关键字是保留的、不允许使用的，否则系统就很难判断究竟是用户写的还是系统生成的；所以，这儿给其加上前缀后，imooc_mall_order表名就没有和关键字重名了；
（3） 表内容解释；
Question
表设计规范有注意到过吗？ 🤗 1.表名不使用复数 2.不同项目使用不同前缀，因为一个公司会有多个项目，需要加上项目名进行区分，加上前缀也能避免与Mysql关键词冲突，何乐而不为呢？
2.imooc_mall_category目录表；
然后，如果一个目录是一级目录，其parent_id是0；
3.imooc_mall_product商品表；
4.imooc_mall_cart购物车表；
5.imooc_mall_order订单表；
说明：可以设想一下，比如我们下了一个订单，这个订单内容就是我们买了东北大米和帝王蟹两个商品；除了在imooc_mall_order表中新增一条记录来记录这个订单的状态外；似乎，还需要一个表来记录这个订单中的东北大米和帝王蟹这两个具体项目数据的表；由此，就引出了下面的imooc_mall_order_item订单项目表；
6.imooc_mall_order_item订单项目表；
Question
数据库表设计时一些注意点能详细讲讲吗？ 🤗 本人不太喜欢那些过于书面化的措辞，我简单介绍下在数据库设计中一些体会吧
- 尽量解耦，能解尽解，不同表主要关注自己的所需数据，比如用户表就不要就不要加入商品表、订单表的数据，否则会导致逻辑紊乱，难以下手开发
- 按模块进行表的设计，如用户模块就加用户表，商品模块就加商品表，不要走歪路，造成后期维护困难
- 若遇到需要耦合的表，一般选择在新建一个表，只需存储两个表的主键值即可，可以在这个表查询到主键再向联合的两个表查询，比如用户表与订单表，可以一对一，一对多，所以需要进行联合查询，这个是RABC权限设计的思想
- 设计数据表时考虑优化，如varchar与char的存储，日期格式选择以及id尽量不要使用自增，使用UUID，大量的增删查改会导致id会暴增，达到极限
- 考虑后期拓展，比如添加一些冗余字段，主从数据库
- 图片文件等尽量只存储外链，不存数据进去