前言

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

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

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

一.字段與屬性值不同

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

查詢失敗！

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

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

二.表中不存在的屬性

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

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

三.表中不存在的屬性

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

@TableField注解的一個屬性叫select，該屬性設(shè)置默認是否需要查詢該字段的值，true(默認值)表示默認查詢該字段，false表示默認不查詢該字段

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

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

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

四.類名表名不匹配

記得懶羊羊在前段時間解決了一個bug:

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

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

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

五.id自增策略

1.type=IdType.AUTO

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

新增成功后，主鍵ID是一個很長串的內(nèi)容，我們更想要的是按照數(shù)據(jù)庫表字段進行自增長，而且不同的表應(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ù)庫ID自增
     * <p>該類型請確保數(shù)據(jù)庫設(shè)置了 ID自增 否則無效</p>
     */
    AUTO(0),
    /**
     * 該類型為未設(shè)置主鍵類型(注解里等于跟隨全局,全局里約等于 INPUT)
     */
    NONE(1),
    /**
     * 用戶輸入ID
     * <p>該類型可以通過自己注冊自動填充插件進行填充</p>
     */
    INPUT(2),
    /* 以下2種類型、只有當插入對象ID 為空，才自動填充。 */
    /**
     * 分配ID (主鍵類型為number或string）,
     * 默認實現(xiàn)類 {@link com.baomidou.mybatisplus.core.incrementer.DefaultIdentifierGenerator}(雪花算法)
     *
     * @since 3.3.0
     */
    ASSIGN_ID(3),
    /**
     * 分配UUID (主鍵類型為 string)
     * 默認實現(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

通過自己注冊自動填充

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

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

3.雪花算法簡介

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

雪花算法是 64 位 的二進制，1位是符號位，也就是最高位，始終是0，沒有任何意義，因為要是唯一計算機二進制補碼中就是負數(shù)，0才是正數(shù)。41位是時間戳，具體到毫秒，41位的二進制可以使用69年，因為時間理論上永恒遞增，所以根據(jù)這個排序是可以的

4.統(tǒng)一主鍵策略

在以后的項目中，為了不去分別配置每個實體類的主鍵策略，我們可以統(tǒng)一設(shè)置逐漸的策略，就像這樣：

mybatis-plus:
  global-config:
    db-config:
    	id-type: assign_id

這樣就做到一次配置處處統(tǒng)一了！

到此這篇關(guān)于MybatisPlus處理四種表與實體的映射及id自增策略分析的文章就介紹到這了,更多相關(guān)Mybatis表與實體的映射內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論