Emergency management wants to model facility–asset–incident relationships for graph-style traversals inside SQL. Which design should they use?
Select an answer to reveal the explanation.
Short Explanation
Graph node and edge tables are like push-pin maps with strings between shelters, generators, and incidents—you can walk the relationships in SQL instead of guessing from flat lists. Emergency management needs that connected view, not a lonely columnstore or a giant JSON blob.
Full Explanation
Emergency management scenarios naturally form many-to-many relationships among facilities, assets, and incidents. SQL graph node and edge tables give first-class storage for those entities and the links between them, enabling MATCH-style traversals to answer questions such as which generators support which shelters during an active incident. That model keeps relationship semantics inside the engine instead of reconstructing joins from flat lists. A columnstore fact table alone optimizes analytical measures; without edge tables it does not encode traversable facility–asset–incident links. Storing one JSON document per incident may capture a blob of attributes, but unstructured documents lack first-class edge cardinality, constraints, and graph query patterns. An external spreadsheet of facility names is a list, not a relationship graph with edge semantics. Caveat: graph shines for relationship traversal; heavy numeric aggregations over incident measures may still belong in relational or columnstore structures alongside the graph, not exclusively inside edges. Operational check: create node tables for facilities, assets, and incidents plus edge tables for the required links, insert a small municipal sample, and run a MATCH query that returns assets connected to a given facility for a specific incident.