MybatisPlus處理四種表與實(shí)體的映射及id自增策略分析

第MybatisPlus處理四種表與實(shí)體的映射及id自增策略分析目錄前言一.字段與屬性值不同二.表中不存在的屬性三.表中不存在的屬性四.類(lèi)名表名不匹配五.id自增策略1.type=IdType.AUTO2.type=IdType.INPUT3.雪花算法簡(jiǎn)介4.統(tǒng)一主鍵策略

前言

CRUD多了就形成了一種思維定勢(shì)得到的數(shù)據(jù)字段是與實(shí)體類(lèi)中屬性一一對(duì)應(yīng)的，這么一想好像也是中規(guī)中矩，按規(guī)矩辦事。難道表中的字段總是與類(lèi)中的屬性相對(duì)應(yīng)嗎？

上述就是所謂的理想情況，字段與屬性一一對(duì)應(yīng)

下面我們來(lái)探究第一種可能出現(xiàn)的問(wèn)題

一.字段與屬性值不同

我更改了實(shí)體類(lèi)中的屬性看執(zhí)行一條普通的查詢會(huì)報(bào)出什么樣的結(jié)果

查詢失??！

因此，當(dāng)表的列名和模型類(lèi)的屬性名發(fā)生不一致，就會(huì)導(dǎo)致數(shù)據(jù)封裝不到模型對(duì)象，這個(gè)時(shí)候就需要其中一方做出修改

這時(shí)MP的一個(gè)注解幫我們解決了這個(gè)問(wèn)題，MP給我們提供了一個(gè)注解@TableField,使用該注解可以實(shí)現(xiàn)模型類(lèi)屬性名和表的列名之間的映射關(guān)系，就像這樣@TableField(value=password)

二.表中不存在的屬性

當(dāng)實(shí)體類(lèi)中出現(xiàn)了一個(gè)數(shù)據(jù)庫(kù)表不存在的字段，就會(huì)導(dǎo)致生成的sql語(yǔ)句中在select的時(shí)候查詢了數(shù)據(jù)庫(kù)不存在的字段

具體的解決方案用到的還是@TableField注解，它有一個(gè)屬性叫exist，設(shè)置該字段是否在數(shù)據(jù)庫(kù)表中存在，如果設(shè)置為false則不存在，生成sql語(yǔ)句查詢的時(shí)候，就不會(huì)再查詢?cè)撟侄?/p>

三.表中不存在的屬性

操作后可能把一些敏感數(shù)據(jù)查詢到返回給前端，這個(gè)時(shí)候我們就需要限制哪些字段默認(rèn)不要進(jìn)行查詢，按照常理，密碼等隱私信息不應(yīng)該被一同查詢出來(lái)，我們?nèi)绾巫龅綄?duì)這些字段的隱藏呢？還是通過(guò)@TableField注解：

@TableField注解的一個(gè)屬性叫select，該屬性設(shè)置默認(rèn)是否需要查詢?cè)撟侄蔚闹担瑃rue(默認(rèn)值)表示默認(rèn)查詢?cè)撟侄?，false表示默認(rèn)不查詢?cè)撟侄?/p>

名稱(chēng)@TableField類(lèi)型屬性注解位置模型類(lèi)屬性定義上方作用設(shè)置當(dāng)前屬性對(duì)應(yīng)的數(shù)據(jù)庫(kù)表中的字段關(guān)系

value(默認(rèn))：設(shè)置數(shù)據(jù)庫(kù)表字段名稱(chēng)

exist:設(shè)置屬性在數(shù)據(jù)庫(kù)表字段中是否存在，默認(rèn)為true，此屬性不能與value合并使用

select:設(shè)置屬性是否參與查詢，此屬性與select()映射配置不沖突

四.類(lèi)名表名不匹配

記得懶羊羊在前段時(shí)間解決了一個(gè)bug:

簡(jiǎn)而言之，就是實(shí)體類(lèi)的類(lèi)名和數(shù)據(jù)庫(kù)里的表名沒(méi)有做到一致，導(dǎo)致MP不能和表相映射關(guān)聯(lián)。沒(méi)想到學(xué)到后面竟然可以采用注解的方式解決：

MP提供的另外一個(gè)注解@TableName來(lái)設(shè)置表與實(shí)體類(lèi)之間的對(duì)應(yīng)關(guān)系：

這樣，我就再也不用刻意的去按照表名來(lái)寫(xiě)實(shí)體類(lèi)啦！

名稱(chēng)@TableName類(lèi)型類(lèi)注解位置模型類(lèi)定義上方作用設(shè)置當(dāng)前類(lèi)對(duì)應(yīng)于數(shù)據(jù)庫(kù)表關(guān)系相關(guān)屬性value(默認(rèn))：設(shè)置數(shù)據(jù)庫(kù)表名稱(chēng)

五.id自增策略

1.type=IdType.AUTO

剛使用MP時(shí)，我就寫(xiě)了一個(gè)增添的方法，只不過(guò)比較奇怪的是，添加的數(shù)據(jù)主鍵id不是依次遞增的，而是一個(gè)非常奇怪的數(shù)字，就像這樣：

新增成功后，主鍵ID是一個(gè)很長(zhǎng)串的內(nèi)容，我們更想要的是按照數(shù)據(jù)庫(kù)表字段進(jìn)行自增長(zhǎng)，而且不同的表應(yīng)用不同的id生成策略比如:

日志：自增（1,2,3,4，）

訂單：特殊規(guī)則（FQ77948AK3982）

外賣(mài)單：關(guān)聯(lián)地區(qū)日期等信息（5022247653148744）

我們以自增為例：@TableId注解

名稱(chēng)@TableId類(lèi)型屬性注解位置模型類(lèi)中用于表示主鍵的屬性定義上方作用設(shè)置當(dāng)前類(lèi)中主鍵屬性的生成策略相關(guān)屬性value(默認(rèn))：設(shè)置數(shù)據(jù)庫(kù)表主鍵名稱(chēng)

type:設(shè)置主鍵屬性的生成策略，值查照IdType的枚舉值

idType的枚舉類(lèi)中還有很多的策略：

@Getter

publicenumIdType{

*數(shù)據(jù)庫(kù)ID自增

*p該類(lèi)型請(qǐng)確保數(shù)據(jù)庫(kù)設(shè)置了ID自增否則無(wú)效/p

AUTO(0),

*該類(lèi)型為未設(shè)置主鍵類(lèi)型(注解里等于跟隨全局,全局里約等于INPUT)

NONE(1),

*用戶輸入ID

*p該類(lèi)型可以通過(guò)自己注冊(cè)自動(dòng)填充插件進(jìn)行填充/p

INPUT(2),

/*以下2種類(lèi)型、只有當(dāng)插入對(duì)象ID為空，才自動(dòng)填充。*/

*分配ID(主鍵類(lèi)型為number或string）,

*默認(rèn)實(shí)現(xiàn)類(lèi){@linkcom.baomidou.mybatisplus.core.incrementer.DefaultIdentifierGenerator}(雪花算法)

*@since3.3.0

ASSIGN_ID(3),

*分配UUID(主鍵類(lèi)型為string)

*默認(rèn)實(shí)現(xiàn)類(lèi){@linkcom.baomidou.mybatisplus.core.incrementer.DefaultIdentifierGenerator}(UUID.replace("-",""))

ASSIGN_UUID(4);

privatefinalintkey;

IdType(intkey){

this.key=key;

}

接下來(lái)我們看一下另一種策略

2.type=IdType.INPUT

通過(guò)自己注冊(cè)自動(dòng)填充

當(dāng)關(guān)閉數(shù)據(jù)庫(kù)里的自動(dòng)遞增，使用該策略執(zhí)行增添操作時(shí)：

@TableId(type=IdType.INPUT)

@Test

voidtestSave(){

Usersuser=newUsers();

user.setName("暖羊羊");

user.setPw("777");

user.setAge(11);

user.setTel("26262665");

userDao.insert(user);

顯然無(wú)法增添該數(shù)據(jù)，生成的SQL里竟然出現(xiàn)了id而在方法里沒(méi)有傳入id，所以我們需要自己填入：

@Test

voidtestSave(){

Usersuser=newUsers();

user.setId(77L);

user.setName("暖羊羊");

user.setPw("777");

user.setAge(11);

user.setTel("26262665");

userDao.insert(user);

最后也是完成了增添

NONE不設(shè)置id生成策略INPUT用戶手工輸入idASSIGN_ID雪花算法生成id(可兼容數(shù)值型與字符串型)ASSIGN_UUID以UUID生成算法作為id生成策略

也是查閱了一下各種策略的優(yōu)缺：

NONE:不設(shè)置id生成策略，MP不自動(dòng)生成，約等于INPUT,所以這兩種方式都需要用戶手動(dòng)設(shè)置，但是手動(dòng)設(shè)置第一個(gè)問(wèn)題是容易出現(xiàn)相同的ID造成主鍵沖突，為了保證主鍵不沖突就需要做很多判定，實(shí)現(xiàn)起來(lái)比較復(fù)雜AUTO:數(shù)據(jù)庫(kù)ID自增,這種策略適合在數(shù)據(jù)庫(kù)服務(wù)器只有1臺(tái)的情況下使用,不可作為分布式ID使用ASSIGN_UUID:可以在分布式的情況下使用，而且能夠保證唯一，但是生成的主鍵是32位的字符串，長(zhǎng)度過(guò)長(zhǎng)占用空間而且還不能排序，查詢性能也慢ASSIGN_ID:可以在分布式的情況下使用，生成的是Long類(lèi)型的數(shù)字，可以排序性能也高，但是生成的策略和服務(wù)器時(shí)間有關(guān)，如果修改了系統(tǒng)時(shí)間就有可能導(dǎo)致出現(xiàn)重復(fù)主鍵

3.雪花算法簡(jiǎn)介

使用一個(gè)64bit的long型的數(shù)字作為全局唯一ID。在分布式系統(tǒng)中的應(yīng)用十分廣泛，且ID引入了時(shí)間戳，基本上保持自增

雪花算法是64位的二進(jìn)制，1位是符號(hào)位，也就是最高位，始終是0，沒(méi)有任何意義，因?yàn)橐俏ㄒ挥?jì)算機(jī)二進(jìn)制補(bǔ)碼中就是負(fù)數(shù)，0才是正數(shù)。41位是時(shí)間戳，具體到毫秒，41位的二