MybatisPlus處理四種表與實(shí)體的映射及id自增策略分析
前言
CRUD多了就形成了一種思維定勢——得到的數(shù)據(jù)字段是與實(shí)體類中屬性一一對應(yīng)的,這么一想好像也是中規(guī)中矩,按規(guī)矩辦事。難道表中的字段總是與類中的屬性相對應(yīng)嗎?

上述就是所謂的理想情況,字段與屬性一 一對應(yīng)
下面我們來探究第一種可能出現(xiàn)的問題
一.字段與屬性值不同
我更改了實(shí)體類中的屬性看執(zhí)行一條普通的查詢會報(bào)出什么樣的結(jié)果

查詢失?。?/p>
因此,當(dāng)表的列名和模型類的屬性名發(fā)生不一致,就會導(dǎo)致數(shù)據(jù)封裝不到模型對象,這個(gè)時(shí)候就需要其中一方做出修改
這時(shí)MP的一個(gè)注解幫我們解決了這個(gè)問題,MP給我們提供了一個(gè)注解@TableField,使用該注解可以實(shí)現(xiàn)模型類屬性名和表的列名之間的映射關(guān)系,就像這樣@TableField(value = "password")

二.表中不存在的屬性
當(dāng)實(shí)體類中出現(xiàn)了一個(gè)數(shù)據(jù)庫表不存在的字段,就會導(dǎo)致生成的sql語句中在select的時(shí)候查詢了數(shù)據(jù)庫不存在的字段

具體的解決方案用到的還是@TableField注解,它有一個(gè)屬性叫exist,設(shè)置該字段是否在數(shù)據(jù)庫表中存在,如果設(shè)置為false則不存在,生成sql語句查詢的時(shí)候,就不會再查詢該字段
三.表中不存在的屬性
操作后可能把一些敏感數(shù)據(jù)查詢到返回給前端,這個(gè)時(shí)候我們就需要限制哪些字段默認(rèn)不要進(jìn)行查詢,按照常理,密碼等隱私信息不應(yīng)該被一同查詢出來,我們?nèi)绾巫龅綄@些字段的隱藏呢?還是通過@TableField注解:

@TableField注解的一個(gè)屬性叫select,該屬性設(shè)置默認(rèn)是否需要查詢該字段的值,true(默認(rèn)值)表示默認(rèn)查詢該字段,false表示默認(rèn)不查詢該字段
| 名稱 | @TableField |
|---|---|
| 類型 | 屬性注解 |
| 位置 | 模型類屬性定義上方 |
| 作用 | 設(shè)置當(dāng)前屬性對應(yīng)的數(shù)據(jù)庫表中的字段關(guān)系 |
value(默認(rèn)):設(shè)置數(shù)據(jù)庫表字段名稱
exist: 設(shè)置屬性在數(shù)據(jù)庫表字段中是否存在,默認(rèn)為true,此屬性不能與value合并使用
select: 設(shè)置屬性是否參與查詢,此屬性與select()映射配置不沖突
四.類名表名不匹配
記得懶羊羊在前段時(shí)間解決了一個(gè)bug:

簡而言之,就是實(shí)體類的類名和數(shù)據(jù)庫里的表名沒有做到一致,導(dǎo)致MP不能和表相映射關(guān)聯(lián)。沒想到學(xué)到后面竟然可以采用注解的方式解決:
MP提供的另外一個(gè)注解@TableName來設(shè)置表與實(shí)體類之間的對應(yīng)關(guān)系:

這樣,我就再也不用刻意的去按照表名來寫實(shí)體類啦!
| 名稱 | @TableName |
|---|---|
| 類型 | 類注解 |
| 位置 | 模型類定義上方 |
| 作用 | 設(shè)置當(dāng)前類對應(yīng)于數(shù)據(jù)庫表關(guān)系 |
| 相關(guān)屬性 | value(默認(rèn)):設(shè)置數(shù)據(jù)庫表名稱 |
五.id自增策略
1.type=IdType.AUTO
剛使用MP時(shí),我就寫了一個(gè)增添的方法,只不過比較奇怪的是,添加的數(shù)據(jù)主鍵id不是依次遞增的,而是一個(gè)非常奇怪的數(shù)字,就像這樣:

新增成功后,主鍵ID是一個(gè)很長串的內(nèi)容,我們更想要的是按照數(shù)據(jù)庫表字段進(jìn)行自增長,而且不同的表應(yīng)用不同的id生成策略比如:
日志:自增(1,2,3,4,……)
訂單:特殊規(guī)則(FQ77948AK3982)
外賣單:關(guān)聯(lián)地區(qū)日期等信息(50 22 24765314 87 44)
我們以自增為例:@TableId注解

| 名稱 | @TableId |
|---|---|
| 類型 | 屬性注解 |
| 位置 | 模型類中用于表示主鍵的屬性定義上方 |
| 作用 | 設(shè)置當(dāng)前類中主鍵屬性的生成策略 |
| 相關(guān)屬性 | value(默認(rèn)):設(shè)置數(shù)據(jù)庫表主鍵名稱 type:設(shè)置主鍵屬性的生成策略,值查照IdType的枚舉值 |
idType的枚舉類中還有很多的策略:
@Getter
public enum IdType {
/**
* 數(shù)據(jù)庫ID自增
* <p>該類型請確保數(shù)據(jù)庫設(shè)置了 ID自增 否則無效</p>
*/
AUTO(0),
/**
* 該類型為未設(shè)置主鍵類型(注解里等于跟隨全局,全局里約等于 INPUT)
*/
NONE(1),
/**
* 用戶輸入ID
* <p>該類型可以通過自己注冊自動填充插件進(jìn)行填充</p>
*/
INPUT(2),
/* 以下2種類型、只有當(dāng)插入對象ID 為空,才自動填充。 */
/**
* 分配ID (主鍵類型為number或string),
* 默認(rèn)實(shí)現(xiàn)類 {@link com.baomidou.mybatisplus.core.incrementer.DefaultIdentifierGenerator}(雪花算法)
*
* @since 3.3.0
*/
ASSIGN_ID(3),
/**
* 分配UUID (主鍵類型為 string)
* 默認(rèn)實(shí)現(xiàn)類 {@link com.baomidou.mybatisplus.core.incrementer.DefaultIdentifierGenerator}(UUID.replace("-",""))
*/
ASSIGN_UUID(4);
private final int key;
IdType(int key) {
this.key = key;
}
}接下來我們看一下另一種策略
2.type=IdType.INPUT
通過自己注冊自動填充
當(dāng)關(guān)閉數(shù)據(jù)庫里的自動遞增,使用該策略執(zhí)行增添操作時(shí):
@TableId(type = IdType.INPUT)
@Test
void testSave() {
Users user = new Users();
user.setName("暖羊羊");
user.setPw("777");
user.setAge(11);
user.setTel("26262665");
userDao.insert(user);
}

顯然無法增添該數(shù)據(jù),生成的SQL里竟然出現(xiàn)了id而在方法里沒有傳入id,所以我們需要自己填入:
@Test
void testSave() {
Users user = new Users();
user.setId(77L);
user.setName("暖羊羊");
user.setPw("777");
user.setAge(11);
user.setTel("26262665");
userDao.insert(user);
}
最后也是完成了增添

| NONE | 不設(shè)置id生成策略 |
|---|---|
| INPUT | 用戶手工輸入id |
| ASSIGN_ID | 雪花算法生成id(可兼容數(shù)值型與字符串型) |
| ASSIGN_UUID | 以UUID生成算法作為id生成策略 |
也是查閱了一下各種策略的優(yōu)缺:
- NONE: 不設(shè)置id生成策略,MP不自動生成,約等于INPUT,所以這兩種方式都需要用戶手動設(shè)置,但是手動設(shè)置第一個(gè)問題是容易出現(xiàn)相同的ID造成主鍵沖突,為了保證主鍵不沖突就需要做很多判定,實(shí)現(xiàn)起來比較復(fù)雜
- AUTO:數(shù)據(jù)庫ID自增,這種策略適合在數(shù)據(jù)庫服務(wù)器只有1臺的情況下使用,不可作為分布式ID使用
- ASSIGN_UUID:可以在分布式的情況下使用,而且能夠保證唯一,但是生成的主鍵是32位的字符串,長度過長占用空間而且還不能排序,查詢性能也慢
- ASSIGN_ID:可以在分布式的情況下使用,生成的是Long類型的數(shù)字,可以排序性能也高,但是生成的策略和服務(wù)器時(shí)間有關(guān),如果修改了系統(tǒng)時(shí)間就有可能導(dǎo)致出現(xiàn)重復(fù)主鍵
3.雪花算法簡介
使用一個(gè) 64 bit 的 long 型的數(shù)字作為全局唯一 ID。在分布式系統(tǒng)中的應(yīng)用十分廣泛,且 ID 引入了時(shí)間戳,基本上保持自增

雪花算法是 64 位 的二進(jìn)制,1位是符號位,也就是最高位,始終是0,沒有任何意義,因?yàn)橐俏ㄒ挥?jì)算機(jī)二進(jìn)制補(bǔ)碼中就是負(fù)數(shù),0才是正數(shù)。41位是時(shí)間戳,具體到毫秒,41位的二進(jìn)制可以使用69年,因?yàn)闀r(shí)間理論上永恒遞增,所以根據(jù)這個(gè)排序是可以的
4.統(tǒng)一主鍵策略
在以后的項(xiàng)目中,為了不去分別配置每個(gè)實(shí)體類的主鍵策略,我們可以統(tǒng)一設(shè)置逐漸的策略,就像這樣:
mybatis-plus:
global-config:
db-config:
id-type: assign_id這樣就做到一次配置處處統(tǒng)一了!
到此這篇關(guān)于MybatisPlus處理四種表與實(shí)體的映射及id自增策略分析的文章就介紹到這了,更多相關(guān)Mybatis表與實(shí)體的映射內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Spring?Boot?+?EasyExcel?+?SqlServer?進(jìn)行批量處理數(shù)據(jù)的高效方法
在日常開發(fā)和工作中,我們可能要根據(jù)用戶上傳的文件做一系列的處理,本篇文章就以Excel表格文件為例,主要介紹了Spring?Boot?+?EasyExcel?+?SqlServer?進(jìn)行批量處理數(shù)據(jù)的高效方法,需要的朋友可以參考下2024-06-06
mybatis-plus 擴(kuò)展批量新增的實(shí)現(xiàn)
本文主要介紹了mybatis-plus 擴(kuò)展批量新增的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-01-01
Java實(shí)現(xiàn)非阻塞式服務(wù)器的示例代碼
這篇文章主要為大家詳細(xì)介紹了如何利用Java實(shí)現(xiàn)一個(gè)簡單的非阻塞式服務(wù)器,文中的示例代碼講解詳細(xì),具有一定的學(xué)習(xí)價(jià)值,需要的可以參考一下2023-05-05
使用React和springboot做前后端分離項(xiàng)目的步驟方式
這篇文章主要介紹了使用React和springboot做前后端分離項(xiàng)目的步驟方式,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-08-08
Java編程生產(chǎn)者消費(fèi)者實(shí)現(xiàn)的四種方法
Java生產(chǎn)者和消費(fèi)者問題是線程安全模型中的經(jīng)典問題:生產(chǎn)者和消費(fèi)者在同一個(gè)時(shí)間段共用同一個(gè)存儲空間,生產(chǎn)者向存儲空間中添加產(chǎn)品呢,消費(fèi)者取走產(chǎn)品,當(dāng)存儲空間為空時(shí),消費(fèi)者阻塞,當(dāng)存儲空間滿時(shí),生產(chǎn)者阻塞2021-10-10
Spring Boot整合Spring Security簡單實(shí)現(xiàn)登入登出從零搭建教程
這篇文章主要給大家介紹了關(guān)于Spring Boot整合Spring Security簡單實(shí)現(xiàn)登入登出從零搭建的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來一起看看吧2018-09-09
淺談SpringBoot是如何實(shí)現(xiàn)日志的
這篇文章主要介紹了淺談SpringBoot是如何實(shí)現(xiàn)日志的,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-03-03

