假设我有一组有向图。我需要查询这些图表。我想对图形建模任务的最佳选择有所了解。到目前为止，我有这些选项，但请不要犹豫，建议其他人：
专有实现（矩阵） 和图遍历算法。
RDBM 和 SQL 选项（太占空间）
RDF 和 SPARQL 选项（太慢）
你们有什么建议？问候。
编辑：只是为了回答 Mad 的问题：
每一个都比较小，不超过200个顶点，400个边。但是，它们有数百个。
查询频率：很难说，这是一个实验系统。
速度：不是实时的，而是实用的，比如 4-5 秒。
【问题讨论】：
标签： graph
您没有向我们提供足够的信息，无法提供深思熟虑的答案。例如：这些图表的大小是多少？您希望以什么频率查询这些图表？您需要实时响应这些查询吗？详细了解您的应用程序的用途、目的是什么，将会有所帮助。
无论如何，为了反驳假设基于 SQL 的 DBMS 无法有效处理图形结构的常见反应，我将提供一些参考：
5 结论和未来工作
在论文中，我们提出了一种新的基于现成的图转换引擎 关系数据库。在勾勒出我们方法的主要概念之后，我们进行了 拿出几个测试用例，通过比较来评估我们的原型实现 AGG [5] 和 PROGRES [18] 工具的转换引擎。
从我们的实验中可以得出的主要结论是关系 数据库提供了一个有前途的候选者作为图的实现框架 转换引擎。我们提请注意我们有希望的实验 结果是使用最坏情况评估方法获得的，即通过重新计算 从头开始应用下一条规则的观点仍然非常低效， 特别是对于具有大量独立匹配的模型转换 相同的规则。 ...
他们使用PostgreSQL 作为 DBMS，这可能不是特别擅长这种应用程序。你可以试试LucidDB，看看它是否更好，我怀疑。
.. 我们表明，如果允许某些辅助关系，则可以在 SQL 中维护传递闭包、交替路径、同一代和其他递归查询。事实上，它们都可以使用最多 2 次元的辅助关系来维持。..
编辑：您提供了更多详细信息，所以...我认为最好的方法是使用主内存专用图形库和基于 DBMS 的解决方案进行一些试验，然后仔细评估两种解决方案的优缺点。
例如：需要安装 DBMS（如果您不使用像 SQLite 这样的“可嵌入” DBMS），只有您知道是否/在何处需要部署您的应用程序以及您的用户是什么。另一方面，DBMS 给您带来立竿见影的好处，例如持久性（我不知道图形库为持久化他们的图提供了什么支持）、事务管理和无数其他。这些与您的应用相关吗？再说一次，只有你知道。
【讨论】：
您提到的第一个选项似乎最好。如果您的图表没有很多边 (|E|=O(|V|))，那么您可能会使用 Dictionary 获得更好的时间和空间复杂性：
var graph = new Dictionary<Vertex, HashSet<Vertex>>();
一个有趣的图形库是QuickGraph。从未使用过，但看起来很有希望:)
【讨论】：
我为各种编程竞赛和生产代码编写并设计了很多图形算法。而且我注意到，每次我需要一个时，我都必须从头开始开发它，将图论中的概念（BFS、DFS、拓扑排序等）组合在一起。
也许缺乏经验是一个原因，但在我看来，仍然没有合理的通用查询语言来解决图形问题。选择几个通用图形库并用编程（而不是查询！）语言解决您的特定任务。这将为您提供最佳性能和空间消耗，但还需要了解图论的基本概念及其局限性。
最后一个：不要对图表使用 SQL。
【讨论】：