Question

假设我有一组有向图。我需要查询这些图表。我想感受一下图形建模任务的最佳选择。到目前为止，我有这些选择，但请不要犹豫，建议别人：

专有实现（矩阵）和图遍历算法。
RDBM和SQL选项（太占用空间）
RDF和SPARQL选项（太慢）

你们会建议什么？问候。

编辑：只是回答Mad的问题：

每个都相对较小，不超过200个顶点，400个边缘。但是，有数百个。
查询频率：很难说，这是一个实验系统。
速度：不是实时，但实用，比如说4-5秒。

Answer 1

你没有给我们足够的信息来回答一个深思熟虑的答案。例如：这些图表的大小是多少？您期望查询这些图表的频率是多少？您是否需要对这些查询进行实时响应？有关您的申请的详细信息，您的目的是什么，将会有所帮助。

无论如何，为了对抗假设基于SQL的DBMS无法有效处理图形结构的常见响应，我将提供一些参考：

Graph Transformation in Relational Databases（。pdf），作者：G. Varro，K。Friedl，D。Varro，于International Workshop on Graph-Based Tools (GraBaTs) 2004呈现;

5结论和未来工作

在本文中，我们提出了一种基于现成的新图形转换引擎关系数据库。在概述了我们的方法的主要概念后，我们进行了通过比较它来评估我们的原型实现的几个测试用例 AGG [5]和PROGRES [18]工具的转换引擎。
从我们的实验中可以得出的主要结论是关系数据库提供了一个有希望的候选者作为图的实现框架转型引擎。我们呼吁关注我们有希望的实验这一事实结果是使用最坏情况评估方法，即通过重新计算获得的从头开始应用的下一条规则的观点仍然非常低效，特别是对于具有大量独立匹配的模型转换同样的规则。 ...

他们使用PostgreSQL作为DBMS，这可能不是特别擅长这种应用程序。您可以尝试LucidDB，看看它是否更好，我怀疑。

Incremental SQL Queries（这里不止一篇论文，你应该专注于“维护SQL中图形的传递关闭”）：“

< / p>

..我们表明，如果允许一些辅助关系，可以在SQL中维护传递闭包，交替路径，相同生成和其他递归查询。事实上，他们都可以使用最多的辅助关系来维护。

Incremental Maintenance of Shortest Distance and Transitive Closure in First Order Logic and SQL。

编辑：您提供了更多详细信息......我认为最好的方法是尝试使用主内存专用图库和基于DBMS的解决方案，然后仔细评估优缺点两种解决方案。

例如：需要安装DBMS（如果您不使用“嵌入式”DBMS，如SQLite），只有您知道是否需要部署应用程序以及您的用户是什么。另一方面，DBMS为您提供直接的好处，例如持久性（我不知道图形库为持久化图形提供了什么支持），事务管理和无数其他。这些与您的申请相关吗？再一次，只有你知道。

Answer 2

您提到的第一个选项似乎最好。如果你的图形没有很多边（| E | = O（| V |））那么你可以使用Dictionary获得更好的时间和空间复杂度：

var graph = new Dictionary<Vertex, HashSet<Vertex>>();

一个有趣的图表库是QuickGraph。从未使用它，但似乎很有希望:)）

Answer 3

我为各种编程竞赛和生产代码编写并设计了相当多的图算法。我注意到每次我需要它时，我必须从头开始，将图论（BFS，DFS，拓扑排序等）中的概念组合在一起。

也许缺乏经验是一个原因，但在我看来，仍然没有合理的通用查询语言来解决图形问题。选择几个通用图形库并用编程（非查询！）语言解决特定任务。这将为您提供最佳的性能和空间消耗，但也需要了解图论的基本概念及其局限性。

最后一个：不将SQL用于图表。

图集的查询语言：数据建模问题

3 个答案: