7.5 更多场景与选型决策：五问收官

7.5 更多场景与选型决策

本节摘要：主数据管理、物联网、身份与权限网络——这些常被问"能不能用图"的场景，各自有清晰的图式要点。本节先快速巡礼三个补充场景，再给出全册收官的五问决策清单：一个新需求到手，五问过完，用不用图、用哪种形态，答案就摆在纸面上。

前四节把最有代表性的场景各走了一遍。本节先补齐三个高频被问到的场景，然后做全册的收官裁决——选型这件事，一章的篇幅都嫌多，一张清单刚刚好。

一、场景补充一：主数据管理（MDM）

主数据的痛点是"同一客户在五个系统里有五副面孔"。图的做法是把所有系统的标识符作为独立节点，用边声明"同一个人的另一副面孔"：

// 同一自然人的多系统身份：标识符节点 + SAME_AS 边
MERGE (p:Party {pid: 'P-9001'})
MERGE (c:Identity {sys: 'CRM', id: 'C-1001'})
MERGE (o:Identity {sys: 'ERP', id: 'E-7788'})
MERGE (c)-[:SAME_AS]->(p)
MERGE (o)-[:SAME_AS]->(p)
​

// 对账查询：找到"挂着多个 CRM 身份"的可疑合并
MATCH (p:Party)<-[:SAME_AS]-(i:Identity {sys: 'CRM'})
WITH p, collect(i.id) AS crmIds
WHERE size(crmIds) > 1
RETURN p.pid, crmIds
​

p.pid    | crmIds
---------|-----------------
"P-9001" | ["C-1001", "C-3345"]   → 人工审核是否合并
​

图的价值在合并决策可视化：哪个身份该并、并完影响哪些账户与订单，一张子图看得清清楚楚——这是表结构里靠人工比对的活。

二、场景补充二：物联网与依赖拓扑

设备、网关、站点组成天然的分形拓扑。图查的是故障域——一个站点掉线，下游哪些设备跟着失联：

// 站点失联的影响面：沿连接关系向下传导
MATCH (site:Site {id: 'SITE-03'})<-[:CONNECTED_TO*1..4]-(dev:Device)
WHERE dev.status = 'online'
RETURN count(dev) AS 受影响设备, collect(dev.type)[..5] AS 类型样例
​

运维大屏上"这次故障影响多少终端"的数字，就是这一行查询的输出。与 7.4 的调用链排障同构：依赖拓扑 + 变长路径 = 影响面分析，这套骨架在工业物联网与 IT 运维（CMDB）里通用。

三、场景补充三：身份与权限网络

"谁能看这份文件"在组织里从来不是一张静态表：人属于组，组有角色，角色授权资源，还有代理与继承。把权限关系本身画成图：

// 递归授权检查：直授权 + 组继承 + 代理链
MATCH (u:User {name: '林晓'})-[:MEMBER_OF*0..3]->(g:Group)
      -[gr:GRANTED]->(r:Resource {id: 'DOC-88'})
RETURN r.id, collect(DISTINCT g.name) AS 授权来源组,
       collect(DISTINCT gr.perm) AS 权限
​

权限审计这类需求在关系库里是"写不动的递归"，在图上是"走两步的事"——金融与政企内网的老大难问题，图的口碑之作。

四、收官：五问决策清单

全册的知识最终要回答一个问题：**手头这个需求，该不该用图？**五问按序裁决：

图：五问决策流程

五问的裁决口径再说明白一点：

问1 问2 是"图的本职"——命中即图有显著收益
问3 是"图的灵活性"——命中加分，但不是决定项
问4 问5 是"图的边界"——不命中就冷静退场：
     纯批量报表交给数仓，亿级全图常驻另算预算
​

把 6.4 的部署三问（合规、人力、波动）接在五问之后，从"用不用图"到"用哪种部署形态"，决策链就完整了。

五、选型后的第一周：落地最小闭环

决策是"用图"之后的第一个动作不是全量迁移，而是两周内跑通一个最小闭环：

第 1～2 天：选一个深关联的子问题，画出建模草图（2.1 三步法）
第 3～4 天：导一份 1～10 万行的样本数据（3.3 的 LOAD CSV 路线）
第 5～7 天：写 3～5 条核心查询（第 2 章），PROFILE 调优
第 8～10 天：与现有方案的查询结果与耗时对账
结论物：一页对比报告——图赢在哪、输在哪、下一步
​

这个闭环的价值在于用真实数据替换预设立场：多数"要不要用图"的争论，输给过一场十天的对照实验。闭环报告里的 PROFILE 数字，比任何架构评审会的雄辩都有说服力。

七、三个"差点上图"的反例

决策清单的反面同样有教育意义，三个真实感十足的反例：

反例一：日志检索
  需求是"按关键字查日志"——没有图结构，全文索引方案更对口。
  五问里只有问3（模型灵活）勉强命中，硬上图只会更慢更贵。

反例二：纯报表统计
  "每天各区域销售额"——单表聚合，列存最优。
  关联深度为一，问1问2双不命中。

反例三：亿级全图实时风控
  问1问2全命中，但问5（量级）严重超标，
  且毫秒级响应要求把 5.3 的算法全推到在线——
  正确姿势是裁剪子图与预计算，而不是"把全图搬进内存"。
​

反例三最典型：它不是"不该用图"，而是"图的用法错了"——把在线与离线分层、把全图问题降维成子图问题，方案就成立了。决策清单淘汰的是伪需求，不是超纲需求。

八、全册收束

从 1.1 的第一张对比表走到这里的决策清单，反复出现的其实是同一件事：把关联当作一等公民来建模、存储与查询。当你下次面对一个需求，能脱口说出它的节点、关系、属性草图，并说出"这段值得图化、那段留给表"的理由——这本教程的目的就达到了。

本节要点回顾

• MDM 用身份标识节点 + SAME_AS 边做归一，合并决策可视化；
• 物联网与 CMDB 共享"依赖拓扑 + 影响面"骨架；
• 权限网络的递归审计是图的口碑场景；
• 五问清单：关联深度、关系价值、模型灵活、在线响应、量级可控；
• 五问之后接 6.4 的部署三问，决策链闭环——全册到此收官。