二、当前元数据存储架构存在的问题

方式一：按照要管理的元数据类型一对一建表

如果要建一个元数据管理系统，只管理字段元数据，那就只需要建这一张表就可以了。但是一个组织里要管理元数据有很多，按照第一种方式，就需要不断的新增加表，以管理更多的元数据。这样就严重破坏了模型的稳定性。一般很少有人采用这种方式。

方式二：通过元模型管理定义元数据的属性

这种方式的缺点就是，违背了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张表才能显示出来。