这是学习笔记的第 1776篇文章
在运维开发中，经常会有类似的需求，这里的数据变化了，另外一个地方也应该发生变化，应该实现级联，看起来是很简单的需求，但是什么时候触发，触发时需要做哪些检查，这些事情细细琢磨起来，发现真是一个浩大的工程，元数据不应该是手工录入，而是应该通过流程来写入。
整体来说，我把元数据流程管理分为了三个部分，接下来会根据这三个维度来简单聊一聊。
第一个基准维度，也就是数据库方向的元数据设计维度，分为了五个部分，有些类别下的子项可能对应一张表，也可能有关联的多个表。根据这五个维度来设计，基本上覆盖面还是比较完整的，可以通过任何一个维度定位到某一台服务器，也可以反向来推。
另外一个是配置维度，这些主要是基于业务属性的配置，根据这些配置能够和业务场景结合起来，或者在业务场景中是需要参考使用的。有了这些维度的基础数据，业务场景就有基准可以参考。
第三部分是业务场景的数据关联，也是本次元数据流程中的重点内容，因为篇幅关系，我做了一些取舍，可以把内容基本收录进来，分成了两部分。这个地方的参考维度，还是希望根据数据的增删改查四个维度来考虑业务场景中的元数据变化。
以上是一个初版，笼统的元数据管理，可以对这些数据变化封装成接口，通过接口的方式来不断的完善和细化这些信息，使得元数据的流程落地相对轻松一些。