c# - 有向图的最佳持久方法/工具/库是什么
C# 中有向图的最佳持久方法/工具/库是什么。假设我有一个有向图的类模型（例如，节点和关系，或者如果您愿意的话，可以是顶点和边），对于持久化到 SQL 数据库，您有什么建议？ （或者如果您希望第二个问题是我不指定 SQL 数据库作为要求）
例如，我想我会简单地使用关系表和节点表。
What is best persistence approach/tool/library for a Directed Graph in C#. That is assuming I have a class model for a directed graph (e.g. Nodes & Relationships, or Vertex's and Edge's if you like), what would you recommend regarding persisting to a SQL Database? (or if you wish a 2nd question would be where I don't specify a SQL database as a requirement)
For example I was thinking I would simply go with a Relationships table and a Nodes table.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不熟悉 C# 中可用的工具，但您的问题似乎主要是关于存储而不是 C#。
毫无疑问，如何存储 DAG 取决于您想到的用例。例如，您可以在关系数据库中的两个表中表示 DAG，其中一个表保存有关节点（A、B、C 等）的信息，另一个表保存有关节点之间的边的信息（A -> B） 、A→C等）。
Neo4j 等图形数据库也可能是一个不错的选择。
当涉及到水平扩展和并发访问时，您的里程会有所不同，具体取决于您采用的方法。您可能希望保留非规范化表示以加速某些类型的查询，但这种策略涉及到您在使用它之前需要了解的权衡。
I'm not familiar with the tools available in C#, but your question seems to be mostly one about storage rather than C#.
How you store a DAG will no doubt depend on the use cases you have in mind. You can represent a DAG in two tables in a relational database, for example, where one table holds information about the nodes (A, B, C, etc.) and another holds information about the edges between the nodes (A -> B, A -> C, etc.).
A graph database such as Neo4j might also be a good way to go.
Your mileage will vary when it comes to things like horizontal scaling and concurrent access, depending on the approach you adopt. You may want to keep a denormalized representation around for speeding up some kinds of queries, but such a strategy involves tradeoffs you'll want to understand before going with it.
节点表和关系（链接）表对我来说似乎是最自然的，因为这通常（总是？）在关系数据库中实现多对多关系，而有向图基本上是多对多关系节点映射（对吗？）。我想您可以将其存储在 XML 字段或某个二进制值中，但这实际上忽略了您拥有数据库的事实。
如果您没有有数据库，并且直接写入某种类型的文件，我可能仍然会使用类似的机制，用键唯一标识每个节点并单独定义键值的方式有关的。
这一切都假设您的有向图是多对多，而不是严格的一对多。如果它是严格的一对多，没有循环，如果写入文件，我可能会使用 XML（利用 XML 中的子元素与其父元素相关的事实），或者如果写入数据库，我可能会使用外键（这将即使存在循环也能正常工作）。
A Nodes table and a Relationships (link) table seems the most natural to me since that's generally (always?) how you implement many-to-many relationships in a relational database, and a directed graph is basically a many-to-many relationship mapping for nodes (right?). I suppose you could store it in an XML field, or some binary value, but that really ignores the fact that you have a database.
If you didn't have a database, and were writing directly to some type of file, I would probably still use a similar mechanism of uniquely identifying each node with a key and separately defining how the key values are related.
This all assumes that your directed graph is many-to-many and not strictly one-to-many. If it were strictly one-to-many, without loops, I might use XML if writing to a file (utilizing the fact that child elements in the XML are related to their parent), or foreign keys if writing to a database (which would work well even if there were loops).