1. 整體設(shè)計為什么用 JDBC 元數(shù)據(jù)接口1.1 先理清需求你要拿到的“表結(jié)構(gòu)信息”到底是什么如果你只是隨口說要“獲取表結(jié)構(gòu)”可能有兩種完全不同的訴求。一種是運維人員想快速看一張表有哪些字段直接執(zhí)行幾條查詢在客戶端里看一眼就完了另一種是開發(fā)要做一個功能模塊比如數(shù)據(jù)字典、元數(shù)據(jù)采集、ORM映射、代碼生成器需要程序化地拿到“表清單—字段—類型—注釋—主鍵”這套結(jié)構(gòu)化信息并且要穩(wěn)定、可重復(fù)執(zhí)行。我之前遇到的場景就是這種某個數(shù)據(jù)中臺項目要把業(yè)務(wù)庫的元數(shù)據(jù)采集到中臺里后續(xù)要同步字段血緣、自動生成測試數(shù)據(jù)、給前端數(shù)據(jù)字典頁面做展示。第一個接入的庫就是達(dá)夢數(shù)據(jù)庫。這個場景下一次性腳本是撐不住的必須做一套可復(fù)用的取數(shù)邏輯于是核心問題就變成了這段代碼怎么設(shè)計才能既兼容達(dá)夢又盡量不鎖死在某一種數(shù)據(jù)庫上。還有一個容易忽略的點字段明細(xì)、類型、長度、精度、是否可空、默認(rèn)值、注釋、主鍵、外鍵這些是常規(guī)信息但一旦落到達(dá)夢上還會引出許多附加問題。比如達(dá)夢支持定義模式下的大寫表名、小寫表名、加引號保留原始大小寫不同用戶訪問同一個表schema 歸屬可能不同注釋可能存在 COMMENT 語句里也可能需要走系統(tǒng)視圖。這些細(xì)節(jié)在設(shè)計數(shù)據(jù)模型時就得先想清楚否則寫出來的代碼只能對付最簡單的 demo稍微換個環(huán)境就各種查不到。1.2 三條技術(shù)路線為什么我傾向 DatabaseMetaData要程序化拿表結(jié)構(gòu)通常有三條路。第一條是查系統(tǒng)表或系統(tǒng)視圖。達(dá)夢的系統(tǒng)視圖有 ALL_TABLES、USER_TABLES、ALL_TAB_COLUMNS、ALL_CONSTRAINTS 這些再深入一點還有 DBA_TABLES。MySQL 則是 information_schema.TABLES、information_schema.COLUMNS。問題一目了然每個數(shù)據(jù)庫的系統(tǒng)表長得不一樣換個庫就要重寫一堆 SQL。更麻煩的是達(dá)夢還有多種兼容模式不同模式下系統(tǒng)視圖的暴露情況不同直接查系統(tǒng)表的代碼很容易出現(xiàn)環(huán)境依賴。第二條路是寫一層“數(shù)據(jù)庫方言適配器”每種數(shù)據(jù)庫實現(xiàn)一套查詢邏輯最后統(tǒng)一對外輸出。很多代碼生成器就是這么做的。優(yōu)點是可控性強(qiáng)可以拿到自增序列、分區(qū)信息這類特殊內(nèi)容缺點是維護(hù)成本高每接一個庫都要寫一套映射而且系統(tǒng)視圖在不同版本之間還會有字段差異。如果團(tuán)隊只維護(hù)一個庫這條路很香如果明確要多庫支持就需要斟酌。第三條路就是我用到的方案直接走 JDBC 標(biāo)準(zhǔn)規(guī)范里的 DatabaseMetaData 接口。JDBC 規(guī)范中定義了 getTables、getColumns、getPrimaryKeys、getImportedKeys 等方法各個數(shù)據(jù)庫驅(qū)動廠商只要遵循標(biāo)準(zhǔn)就會把這些方法實現(xiàn)到本庫的系統(tǒng)表之上。達(dá)夢的 JDBC 驅(qū)動DmJdbcDriver.jar也實現(xiàn)了這些方法。選它作為主干最大的好處是同一份代碼在絕大多數(shù)關(guān)系型數(shù)據(jù)庫上可以直跑遇到個別細(xì)節(jié)問題再針對達(dá)夢做少量補償。有人會質(zhì)疑元數(shù)據(jù)接口的性能。我的實測經(jīng)驗是在幾千張表、幾萬個字段的規(guī)模下通過 JDBC 元數(shù)據(jù)接口讀取耗時在幾十秒到兩三分鐘這個量級完全能接受。相比之下寫幾十個精心優(yōu)化的系統(tǒng)表查詢省出來的時間并不多而且通用性帶來的收益通常遠(yuǎn)超這幾分鐘的開銷。1.3 達(dá)夢的“兼容”與“不兼容”達(dá)夢數(shù)據(jù)庫有一個顯著特點它提供 Oracle 兼容模式很多語法、數(shù)據(jù)類型、系統(tǒng)視圖命名都向 Oracle 靠攏。這也導(dǎo)致一個常見誤區(qū)——默認(rèn)達(dá)夢和 Oracle 完全一致直接把 Oracle 那套代碼搬過來就完事。實際上達(dá)夢的 JDBC 驅(qū)動在元數(shù)據(jù)行為上和 Oracle 驅(qū)動有不少差異。最典型的是模式名Schema的處理。達(dá)夢在用戶登錄后默認(rèn)模式一般就是用戶名對應(yīng)的模式但如果配置了“模式名與用戶名不一致”或者用高權(quán)限用戶連接而你要讀的是別人名下的表那調(diào)用 getTables 時catalog 和 schema 參數(shù)怎么傳就特別講究。達(dá)夢驅(qū)動有時候會把 catalog 和 schema 混在一起處理你只傳 schema 不傳 catalog結(jié)果可能為空你把 schema 當(dāng) catalog 傳返回結(jié)果又可能出乎意料。我調(diào)試最久的就集中在這一塊。另一個特殊點是大小寫。達(dá)夢默認(rèn)把不帶引號的表名、字段名轉(zhuǎn)成大寫存儲但建表時加了雙引號名稱會保留原始大小寫。JDBC 元數(shù)據(jù)接口做匹配時getTables 的 tableNamePattern 參數(shù)是按數(shù)據(jù)庫內(nèi)部存儲的字符串去匹配的。也就是說你拿小寫字符串去匹配一個默認(rèn)創(chuàng)建的大寫表名很可能匹配不上。這個問題直接影響了后面所有查詢邏輯我放到 2.4 節(jié)專門講。2. 核心實現(xiàn)把“通用”做扎實的分層設(shè)計2.1 統(tǒng)一數(shù)據(jù)模型先行在寫讀表邏輯之前先要把結(jié)果的數(shù)據(jù)結(jié)構(gòu)定義好。所謂“通用”不是說不考慮數(shù)據(jù)庫差異而是先把差異擋在模型外面上層拿到的東西保持一致。我當(dāng)時設(shè)計了四個基礎(chǔ)模型TableInfo表名、表類型、所屬 schema、注釋、是否視圖等基礎(chǔ)屬性。ColumnInfo字段名、JDBC 類型碼、數(shù)據(jù)庫原生類型字符串、長度、精度、是否可空、默認(rèn)值、注釋、字段序號。PrimaryKeyInfo主鍵名、主鍵字段集合、聯(lián)合主鍵中每個字段的順序。這個順序很關(guān)鍵聯(lián)合主鍵順序錯了生成索引 DDL 時會出問題。ImportedKeyInfo外鍵信息包含外鍵表名、外鍵字段、引用表名、引用字段、更新規(guī)則、刪除規(guī)則。要注意一點模型里不要只存數(shù)據(jù)庫原生類型字符串。因為達(dá)夢返回的 typeName 可能是 VARCHAR、VARCHAR2、NVARCHAR2 這樣五花八門的值。比較類型時優(yōu)先用 dataType 這個 JDBC 類型碼再結(jié)合實際長度做判斷。比如判斷“字符串類型”不能只檢查 typeName 是不是 varchar應(yīng)該看 getColumnType() 返回的是 Types.VARCHAR 還是 Types.NVARCHAR再結(jié)合長度做后續(xù)分支。模型字段宜多不宜少。我吃過虧最初只設(shè)計了列名和類型后面數(shù)據(jù)字典頁面需要展示默認(rèn)值和自增標(biāo)志又回來改模型。元數(shù)據(jù)采集這種功能一次把模型定義寬一點后面省很多事。2.2 讀取層用 DatabaseMetaData 串起所有信息核心代碼不多重點在于理解每一次調(diào)用的參數(shù)。我寫一個不依賴數(shù)據(jù)庫特性的類內(nèi)部持有 Connection通過 connection.getMetaData() 拿到 DatabaseMetaData 對象然后逐層讀取。獲取表清單的核心方法如下public ListTableInfo listTables(Connection conn, String schemaPattern, String tableNamePattern) throws SQLException { ListTableInfo tables new ArrayList(); DatabaseMetaData metaData conn.getMetaData(); ResultSet rs metaData.getTables( conn.getCatalog(), // catalog達(dá)夢一般傳 null 或者當(dāng)前庫 schemaPattern, // schema傳模式名支持 % 通配符 tableNamePattern, // 表名模式支持 % 通配符 new String[]{TABLE, VIEW} // 只取表和視圖 ); while (rs.next()) { TableInfo info new TableInfo(); info.setTableCat(rs.getString(TABLE_CAT)); info.setTableSchema(rs.getString(TABLE_SCHEM)); info.setTableName(rs.getString(TABLE_NAME)); info.setTableType(rs.getString(TABLE_TYPE)); info.setRemarks(rs.getString(REMARKS)); tables.add(info); } rs.close(); return tables; }這里有一個關(guān)鍵參數(shù)策略達(dá)夢下catalog 參數(shù)到底傳什么。我實測下來最穩(wěn)的做法是 catalog 傳 nullschema 傳要查詢的模式名。部分版本的達(dá)夢驅(qū)動會把 catalog 當(dāng)成 Oracle 的實例名處理傳了反而查不到結(jié)果。而 schema 傳大寫模式名返回最穩(wěn)定。如果拿不準(zhǔn)模式名的大小寫可以先傳一個 % 通配符拿到當(dāng)前用戶可見的所有模式再從中過濾。然后是字段信息public ListColumnInfo listColumns(Connection conn, String schemaPattern, String tableName) throws SQLException { ListColumnInfo columns new ArrayList(); DatabaseMetaData metaData conn.getMetaData(); ResultSet rs metaData.getColumns(conn.getCatalog(), schemaPattern, tableName, %); while (rs.next()) { ColumnInfo col new ColumnInfo(); col.setColumnName(rs.getString(COLUMN_NAME)); col.setDataType(rs.getInt(DATA_TYPE)); col.setTypeName(rs.getString(TYPE_NAME)); col.setColumnSize(rs.getInt(COLUMN_SIZE)); col.setDecimalDigits(rs.getInt(DECIMAL_DIGITS)); col.setNullable(rs.getInt(NULLABLE)); col.setRemarks(rs.getString(REMARKS)); col.setOrdinalPosition(rs.getInt(ORDINAL_POSITION)); col.setDefaultValue(rs.getString(COLUMN_DEF)); columns.add(col); } rs.close(); return columns; }在達(dá)夢下getColumns 返回的 IS_AUTOINCREMENT 列也支持它返回 YES 或 NO可以用來判斷自增字段。不過有些版本的驅(qū)動在這列取值上不穩(wěn)定更嚴(yán)謹(jǐn)?shù)淖龇ㄊ悄孟到y(tǒng)視圖 ALL_TAB_COLUMNS 中 IDENTITY 相關(guān)字段做補充確認(rèn)。這就是典型的“通用代碼 方言補償”配合通用主干保持干凈方言細(xì)節(jié)藏在補償分支里。主鍵讀取public PrimaryKeyInfo getPrimaryKey(Connection conn, String schemaPattern, String tableName) throws SQLException { PrimaryKeyInfo pk new PrimaryKeyInfo(); ListString pkColumns new ArrayList(); DatabaseMetaData metaData conn.getMetaData(); ResultSet rs metaData.getPrimaryKeys(conn.getCatalog(), schemaPattern, tableName); while (rs.next()) { pk.setPkName(rs.getString(PK_NAME)); pkColumns.add(rs.getString(COLUMN_NAME)); // KEY_SEQ 表示聯(lián)合主鍵中的順序必須記錄起來之后排序 } rs.close(); pk.setColumns(pkColumns); return pk; }主鍵這里有個容易被忽略的問題返回的 ResultSet 不保證按 KEY_SEQ 排序。你需要先把 KEY_SEQ 一起讀進(jìn)內(nèi)存然后對列排序否則聯(lián)合主鍵的列順序是隨機(jī)的。我后面實操時真遇上了第一次生成的 DDL 里聯(lián)合主鍵順序是反的。2.3 類型映射先判 JDBC 類型碼再看原生類型通用代碼搭起來之后馬上會遇到第一個跨庫不一致點類型映射。我建議用一個獨立方法把 JDBC 類型碼轉(zhuǎn)換成語義明確的邏輯類型public static String mapJdbcType(int jdbcType, String typeName, int size, int decimalDigits) { switch (jdbcType) { case Types.INTEGER: case Types.SMALLINT: case Types.TINYINT: return int; case Types.BIGINT: return long; case Types.VARCHAR: case Types.NVARCHAR: return String; case Types.DECIMAL: case Types.NUMERIC: return decimal; case Types.DATE: return Date; case Types.TIMESTAMP: return Timestamp; case Types.CLOB: return text; case Types.BLOB: return binary; default: return typeName; } }關(guān)鍵點在順序和優(yōu)先級。先看 JDBC 類型碼再看原生類型名。達(dá)夢里 DECIMAL(10,2) 的 JDBC 類型碼是 Types.DECIMALNUMBER 類型有時候返回 Types.NUMERIC有時候返回 Types.DECIMAL兩個 case 都要處理否則代碼生成會漏分支。注釋讀取也有一個細(xì)節(jié)JDBC 元數(shù)據(jù)接口的 REMARKS 字段在達(dá)夢上能返回通過 COMMENT ON 語句寫入的備注建表時指定了字段注釋也能正常返回。如果你需要的不只是簡單的字段注釋而是表級注釋甚至更復(fù)雜的說明getTables 的 REMARKS 可能不夠用。我當(dāng)時的做法是表級注釋先用 REMARKS信息不全時再查 ALL_TAB_COMMENTS 做一輪補償。補償查詢務(wù)必限定在某個 schema 下否則多用戶模式下會查到別人表里的注釋。2.4 大小寫策略達(dá)夢里最容易被忽略的問題在達(dá)夢上表名和模式名的匹配規(guī)則與建表時的寫法直接相關(guān)。默認(rèn)情況下不帶雙引號的名稱會被轉(zhuǎn)成大寫存儲。所以庫里的表名通過 getTables 返回的通常是 BUY_ORDER_DETAIL 這種全大寫。如果你的應(yīng)用層習(xí)慣用駝峰命名 buyOrderDetail直接拿這個名字做 pattern 去匹配是匹配不到的。我在設(shè)計通用代碼時加了一個策略開關(guān)是否對入?yún)⒈砻鼋y(tǒng)一轉(zhuǎn)大寫處理。針對達(dá)夢默認(rèn)開啟“無引號名稱轉(zhuǎn)大寫”的預(yù)處理而在 MySQL 這類存儲時保留大小寫的庫上這個開關(guān)必須關(guān)閉。實現(xiàn)不復(fù)雜在調(diào)用 getTables 和 getColumns 之前做一次規(guī)范化private String normalizeName(String name, boolean upperCaseStrategy) { if (name null) return null; if (upperCaseStrategy) { return name.toUpperCase(); } return name; }這里還有更深一層的問題如果用戶建表時用了雙引號比如 create table BuyOrderDetail存儲名稱就是混合大小寫直接轉(zhuǎn)大寫反而匹配不上。所以更穩(wěn)的做法是先查一遍表清單把實際表名集合加載到內(nèi)存應(yīng)用層再做一次不區(qū)分大小寫的匹配找到真實表名后再傳給 getColumns。雖然多查詢一次但換來了穩(wěn)定。這個方案通用性最好。我最終保留了兩層匹配邏輯第一層用規(guī)范后的名字直接查第二層查不到時把當(dāng)前 schema 下的表清單全量拉出來做不區(qū)分大小寫匹配找到真實表名后再去取列。這段邏輯對上層完全透明在達(dá)夢上靠它救了不少場景。3. 實操過程在達(dá)夢上完整跑通這套代碼3.1 步驟一驅(qū)動、連接與版本確認(rèn)達(dá)夢的 JDBC 驅(qū)動引用不復(fù)雜驅(qū)動類是 dm.jdbc.driver.DmDriver連接 URL 形如 jdbc:dm://192.168.x.x:5236/數(shù)據(jù)庫名。驅(qū)動包通常是 DmJdbcDriver.jar不同版本內(nèi)部類名基本穩(wěn)定。連接參數(shù)里第一個要關(guān)注的坑是字符集。有的部署環(huán)境客戶端字符集和數(shù)據(jù)庫服務(wù)端不一致會導(dǎo)致元數(shù)據(jù)查詢返回的字符串出現(xiàn)亂碼。建議在連接串里顯式指定字符集設(shè)置或者通過應(yīng)用側(cè)的連接配置來控制。具體寫法依驅(qū)動版本略有差異穩(wěn)妥的做法是先看官方連接參數(shù)說明確認(rèn)支持哪些字符集參數(shù)再配置到連接池里。初次接入時強(qiáng)烈建議先寫一個獨立測試類把數(shù)據(jù)庫版本和驅(qū)動版本打印出來DatabaseMetaData md conn.getMetaData(); System.out.println(md.getDatabaseProductName()); System.out.println(md.getDatabaseProductVersion()); System.out.println(md.getDriverName()); System.out.println(md.getDriverVersion());這一步值得做。它會直接告訴你驅(qū)動對應(yīng)的兼容行為和版本后面遇到怪問題時版本信息是排查的重要依據(jù)。3.2 步驟二把表清單打印出來用前面的 listTables 方法在達(dá)夢實例上跑一次。我的測試過程是先用當(dāng)前登錄用戶默認(rèn) schema 查詢能正常返回一批表接著切換到另一個業(yè)務(wù)用戶模式查詢這時需要把 schemaPattern 參數(shù)傳成對應(yīng)的大寫模式名否則結(jié)果為空。輸出樣例大致是下面這種形式TABLE_SCHEMADMUSER1, TABLE_NAMEBUY_ORDER_DETAIL, TYPETABLE, REMARKS訂單明細(xì)表 TABLE_SCHEMADMUSER1, TABLE_NAMEPRODUCT_CATEGORY, TYPEVIEW, REMARKS商品分類視圖如果 REMARKS 返回空先別急著懷疑代碼。到數(shù)據(jù)庫客戶端里執(zhí)行一句SELECT * FROM ALL_TAB_COMMENTS WHERE TABLE_NAME BUY_ORDER_DETAIL;看看能不能查到表注釋。如果這里也是空說明表本身就沒寫注釋代碼邏輯再對也撈不到內(nèi)容。3.3 步驟三讀取列信息、主鍵、默認(rèn)值與自增列信息是整個模塊的核心。測試時我特意找了兩張表一張是普通流水表字段有十來個類型覆蓋 DATE、VARCHAR2、DECIMAL、NUMBER、CLOB另一張是帶聯(lián)合主鍵、帶自增列、帶外鍵的配置表。第一張表遍歷結(jié)果非常正常類型碼、長度、小數(shù)位數(shù)都按預(yù)期返回。第二張表的聯(lián)合主鍵出了問題getPrimaryKeys 返回的主鍵列順序是亂的KEY_SEQ 有 1、2也有 2、1。我在代碼里補上排序邏輯后解決。自增列的判斷更值得記錄。同一張自增表里自增列在 getColumns 中返回的 IS_AUTOINCREMENT 字段在某些達(dá)夢版本里是 YES某些版本里是空。后來我用這種備用 SQL 做補償SELECT COLUMN_NAME FROM ALL_TAB_IDENTITY_COLS WHERE OWNER UPPER(?) AND TABLE_NAME UPPER(?)這是很典型的思路當(dāng) JDBC 元數(shù)據(jù)拿不到 100% 準(zhǔn)確的細(xì)節(jié)時用目標(biāo)數(shù)據(jù)庫的系統(tǒng)視圖做定向補償補償代碼用配置開關(guān)隔離盡量不讓通用主干混入方言邏輯。3.4 步驟四生成一份可執(zhí)行的 DDL 語句讀完元數(shù)據(jù)后最直接的驗證方法是把它反向生成建表語句。這也是判斷代碼是否“真正讀對了”的硬標(biāo)準(zhǔn)。我寫了一個簡易生成器對每個字段拼出名稱、類型、長度、默認(rèn)值、注釋最后拼主鍵約束。生成過程中遇到兩個達(dá)夢專屬問題。第一個是類型長度拼接。VARCHAR 類型需要長度NUMBER 類型需要精度和小數(shù)位但 CLOB、BLOB、DATE 這些類型不需要。如果統(tǒng)一模板處理就會出現(xiàn) date(0)、clob(0) 這種錯誤。解決方式是在拼 SQL 時判斷 dataTypeif (col.getDataType() Types.VARCHAR || col.getDataType() Types.NVARCHAR) { sb.append(col.getTypeName()).append(().append(col.getColumnSize()).append()); } else if (col.getDataType() Types.DECIMAL || col.getDataType() Types.NUMERIC) { if (col.getDecimalDigits() 0) { sb.append(col.getTypeName()).append(() .append(col.getColumnSize()).append(,) .append(col.getDecimalDigits()).append()); } else { sb.append(col.getTypeName()).append(().append(col.getColumnSize()).append()); } } else { sb.append(col.getTypeName()); }第二個是表名大小寫。建表語句如果沒加雙引號達(dá)夢會直接把表名轉(zhuǎn)大寫但如果原表是用雙引號建的混合大小寫表名生成的 DDL 里去掉了引號就會導(dǎo)致重建出來的表名和原表不一致。所以我生成的 DDL 對表名、字段名默認(rèn)都加雙引號。這個做法驗證下來最穩(wěn)代價是數(shù)據(jù)庫里所有對象名稱都會被嚴(yán)格固定成引號內(nèi)的大小寫。4. 常見問題與坑位總結(jié)4.1 常見問題速查表我把實際操作中最常撞上的問題整理成了一張速查表后面再挑幾個展開細(xì)說。現(xiàn)象可能原因處理方式getTables 返回空結(jié)果schema 傳錯大小寫或 catalog 傳了干擾值將 catalog 置空schema 用大寫模式名重試表清單能查到但 getColumns 返回空表名大小寫不一致實際存儲名稱與傳入 pattern 不同拉取真實表名做不區(qū)分大小寫匹配后再查詢字段注釋始終為空表本身沒寫 COMMENT或驅(qū)動版本問題用系統(tǒng)視圖補償查詢確認(rèn)源頭有值聯(lián)合主鍵順序錯亂驅(qū)動返回順序不穩(wěn)定KEY_SEQ 需要手工排序讀取 KEY_SEQ 字段在內(nèi)存中按順序排序NUMBER 類型映射異常驅(qū)動返回可能是 NUMERIC也可能是 DECIMAL兩個 case 都要處理以 dataType 優(yōu)先判斷CLOB/BLOB 字段拼 DDL 出錯通用模板硬拼長度參數(shù)按類型分組判斷特殊類型不拼接長度自增標(biāo)志在元數(shù)據(jù)中為空驅(qū)動未完整實現(xiàn)該列查詢系統(tǒng)視圖補償用屬性開關(guān)控制啟用4.2 談幾個實際踩過的坑第一個坑與模式有關(guān)。剛開始我按常規(guī)寫法把數(shù)據(jù)庫名傳給 catalog用戶名傳給 schema結(jié)果 getTables 返回 0 行排查了很久。后來看驅(qū)動日志才發(fā)現(xiàn)達(dá)夢 JDBC 驅(qū)動內(nèi)部對 catalog 的理解和 MySQL 不完全一樣。最后把 catalog 去掉只保留 schema結(jié)果才對。第二個坑是注釋。有個表的注釋在客戶端能看到代碼里讀到卻是 null。一開始以為是驅(qū)動解析問題后來才發(fā)現(xiàn)是補償查詢時沒有加 OWNER 條件結(jié)果拿到的是另一個同名表的信息。這個經(jīng)歷讓我學(xué)會了補償 SQL 里必須顯式限定模式絕不能偷懶。第三個坑是生成 DDL 時表名錯亂。原因是原設(shè)計里 DDL 沒有加引號而原表是帶引號的混合大小寫表名重建之后全變成大寫。后來統(tǒng)一給 DDL 里的表名、字段名加雙引號問題才消失。第四個坑不算復(fù)雜但很有代表性getColumns 返回的 COLUMN_SIZE對 NUMBER 類型字段返回的是精度還是最大字節(jié)數(shù)不同版本驅(qū)動之間并不完全一致。如果你的生成邏輯對后者的依賴很強(qiáng)建議在接正式庫前先建一張包含典型類型的測試表把返回結(jié)果和客戶端里的定義逐項比對一遍。這一步能提前發(fā)現(xiàn)驅(qū)動的“特殊解釋”省得以后在真實環(huán)境里反復(fù)折騰。4.3 通用代碼的邊界與后續(xù)擴(kuò)展在達(dá)夢上這套代碼能穩(wěn)定跑起來但我也要潑一點冷水。通用代碼的優(yōu)勢是覆蓋面廣劣勢是每個數(shù)據(jù)庫的特性拿不全?？梢杂醚a償機(jī)制去補齊但補償補到一定程度后代碼會越來越難維護(hù)需要有意識地做取舍。我的經(jīng)驗是如果只做表結(jié)構(gòu)展示、字段清單導(dǎo)出、反向生成基礎(chǔ) DDLJDBC 元數(shù)據(jù)接口完全夠用不需要碰系統(tǒng)表。但如果目標(biāo)是生成精確到分區(qū)策略、表空間、索引結(jié)構(gòu)、存儲參數(shù)、列加密屬性這類深水區(qū)內(nèi)容建議額外寫一個達(dá)夢專屬的方言模塊用系統(tǒng)表和系統(tǒng)視圖作為數(shù)據(jù)源。通用代碼與方言補償代碼分層存在模塊邊界清晰未來接更多數(shù)據(jù)庫時只需要替換方言模塊。我還見過一種延伸做法把通用元數(shù)據(jù)讀取做成命令行小工具輸入連接信息輸出 JSON 或 Markdown 格式的表結(jié)構(gòu)文檔。這個方向很適合做內(nèi)部的數(shù)據(jù)字典導(dǎo)出工具。后續(xù)如果要繼續(xù)擴(kuò)展可以把索引、約束、觸發(fā)器也逐步納入模型但前提是在達(dá)夢上把這些信息的元數(shù)據(jù)行為先驗證清楚。最后說一點個人體會。通用代碼這種東西“通用”是相對而言的我在達(dá)夢上驗證通過不代表換一臺環(huán)境、換一個驅(qū)動版本就萬事大吉。真正要在項目里落地先把數(shù)據(jù)庫版本、驅(qū)動版本、用戶模式和表命名規(guī)范這四樣固定下來在一個穩(wěn)定的環(huán)境基線上跑完整套流程然后才開始接其他庫。做過一遍你就能明白所謂通用不是代碼本身沒有差異分支而是差異設(shè)計在了它該待的地方。