说明
上篇介绍了一下设计方面的想法，这篇主要考虑一下图系统构建工程化的思路。
内容
1 几部分组件
1.1 前端到mongo数据库
我希望这是可以直接辅助工作的，减少负担的系统。在使用上没有比网页来的更简单的了，这部分实践过，基本认为只是消耗时间。
1.2 python到mongo(几种模式)
python到mongo的操作就那些，但是我希望用不同的逻辑去构建。至少需要主表和日志表，日志表和主表之间根据操作号进行同步更新。
主要是可以确保回溯到某个时期的操作。
1.3 python到neo4j的方式
通过py2neo，以cypher操作为主，要完成df向图库的录入，更新和删除。主要采取的逻辑是按照neo4j import约定的样式：
- 1 节点表和关系表分开
- 2 先建节点表再建关系表
- 3 每次的操作最多是一类关系表
- 4 节点表可以一次录入
比较重要的实现是子图操作。根据某个标签号或者cypher模式，批量的选择节点及关系（子图），重新映射为python对象，处理后再重新映射回图库的过程。
2 一些原则
功能极简
按照实现功能的最简单的考虑进行设计和实施，不需要考虑太复杂的内容。例如考虑project_id和schema_id是合理和必须的，而user_id,company_id就有点没必要。
两端到中间，中间到完成
最终如何实现一定是有n种办法的，因为太复杂，具体实现的办法无法事先确定。一种可行的方法是从确定的两端逼近：
- 1 需求端：我想要做成什么样的功能
- 2 工具端：目前我有哪些可用的工具
整个过程是一个折中的过程，需要尽量砍掉现阶段次要的功能；在工具端只需要构建能满足现阶段使用的部件即可，不要盲目扩大。
3 实践先行
等待是下策。
以知识管理为例，可以先基于子图进行表格的录入，直接写入图库进行测试。连接是第二步的事。
以建模过程为例：
- 1 子图名称： SubGraphModelProcess
- 2 节点：原始数据、描述元数据…
- 3 关系：缺失检查
其中特征工程可能又比较复杂，可以将其压缩为一个”节点“。这个节点更多是逻辑上的，事实上是一个子图：
- 1 子图名称：SubGraphFeatureEngineering
- 2 节点：原始数据，差分数据…
- 3 关系：时间特征提取…
连接可以有通用连接，以表达其构造方式，也可以有具体连接，以表达其特定技术。
通用连接有：
- 1 依赖 DependsOn
- 强依赖 Strong：没有就会无法执行
- 弱依赖 Weak: 没有可能会有报警，但不影响执行。
- 2 有关系 HasRelWith
- 等价关系：Same
- 互补关系：Mutex
- 相反关系：Opposite
- 构成部分：ComposeOf
- 递进关系：Upgraded
节点和节点之间如果有关系，那么一定有通用连接，反之未必
具体可以把一些工作内容按照图的方式梳理，然后和neo4j交互，特别是子图交互，看看效果。
