前言

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

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

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

一.字段與屬性值不同

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

查詢失??！

因此，當(dāng)表的列名和模型類的屬性名發(fā)生不一致，就會(huì)導(dǎo)致數(shù)據(jù)封裝不到模型對(duì)象，這個(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ù)庫(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)該被一同查詢出來，我們?nèi)绾巫龅綄?duì)這些字段的隱藏呢？還是通過@TableField注解：

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

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

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

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

四.類名表名不匹配

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

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

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

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

五.id自增策略

1.type=IdType.AUTO

剛使用MP時(shí)，我就寫了一個(gè)增添的方法，只不過比較奇怪的是，添加的數(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）

外賣單：關(guān)聯(lián)地區(qū)日期等信息（50 22 24765314 87 44）

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

idType的枚舉類中還有很多的策略：

@Getter
public enum IdType {
    /**
     * 數(shù)據(jù)庫(kù)ID自增
     * <p>該類型請(qǐng)確保數(shù)據(jù)庫(kù)設(shè)置了 ID自增 否則無效</p>
     */
    AUTO(0),
    /**
     * 該類型為未設(shè)置主鍵類型(注解里等于跟隨全局,全局里約等于 INPUT)
     */
    NONE(1),
    /**
     * 用戶輸入ID
     * <p>該類型可以通過自己注冊(cè)自動(dòng)填充插件進(jìn)行填充</p>
     */
    INPUT(2),
    /* 以下2種類型、只有當(dāng)插入對(duì)象ID 為空，才自動(dòng)填充。 */
    /**
     * 分配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

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

當(dāng)關(guān)閉數(shù)據(jù)庫(kù)里的自動(dòng)遞增，使用該策略執(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);
    }

最后也是完成了增添

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

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

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

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

雪花算法是 64 位 的二進(jìn)制，1位是符號(hào)位，也就是最高位，始終是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)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！