二、當前元數據存儲架構存在的問題

方式一：按照要管理的元數據類型一對一建表

如果要建一個元數據管理系統，只管理字段元數據，那就只需要建這一張表就可以了。但是一個組織里要管理元數據有很多，按照第一種方式，就需要不斷的新增加表，以管理更多的元數據。這樣就嚴重破壞了模型的穩定性。一般很少有人采用這種方式。

方式二：通過元模型管理定義元數據的屬性

這種方式的缺點就是，違背了Java面向對象的編程思想，程序處理邏輯復雜，需要編寫大量的自定義SQL來實現元數據的管理。如下圖所示查詢元數據基本信息的邏輯。除了元數據公共屬性instance_id（ID）, instance_name（名稱）, instance_code（編碼）, parent_id（父ID）, classifier_id（元數據類型）, namespace（上下文命名空間）外，還有fileld這個動態屬性，是需要在java程序中動態拼接的。如下圖所示：

再來看下T_MD_INSTANCE表的結構，如下圖，我們發現里面有大量STRING_1、STRING_2 .....STRING_40的字段。設置40個擴展字段，不會全部用到，用到的代表什么含義由元模型來決定。

以字段元數據來舉例，要知道STRING_8這個字段代表什么含義，需要從元模型表、元模型屬性表和元模型屬性映射表來解讀。

在顯示一個元數據的基本信息的時候，需要通過至少4張表才能顯示出來。