用于存储树/图结构的NoSQL（MongoDB）或SQL（PostgreSQL）

我正处于项目的规划阶段，我有以下情况：

我有一个具有唯一ID、名称和附加信息的元素

每个元素可以有多个父元素和子元素，也可以没有父元素和子元素。比如说

元素A没有父元素和三个子元素B、C和D（它们都是与A相同的类型）

元素B有一个父元素（当然是A）和两个子元素E和F

另一个例子是元素C有两个父元素A和B以及零个或多个子元素

我满足的唯一要求是使用数据库，但我可以在MongoDB或Postgresl之间自由选择。数据经常被读取，但不会被更改

我相信MongoDB是更好的解决方案。有什么想法吗

编辑：按要求提供更多信息：

我对这两方面都没有什么经验，所以知识是无可争辩的。我们现在谈论的参赛作品不到1500件，未来（未来5年）参赛作品数量不会超过5000件

---

我做了一些研究，发现了sql的嵌套集和树的mongoDB文档，我相信mongoDB会更方便

总的来说，我对PostgreSQL和存储树非常满意<使用递归的code>为遍历和导航提供了良好的框架。使用MongoDB时，您可能会被map/reduce卡住

这并不意味着没有多少困难。这些问题是可以解决的，但需要一些努力。最大的问题是递归的

通常用于广度优先搜索。您可以进行深度优先搜索，但这是可能的。请注意，关系数据库在使用集合时经过了高度优化，因此很少需要深度优先搜索。本质上，您的所有搜索策略都采用一套搜索策略

当然，图形比树更复杂，但有很多方法可以做到这一点

现在，我对PostgreSQL的了解比我对MongoDB的了解要好得多，但关系型系统在查询方面通常比NoSQL系统更灵活，我会谨慎地放弃它。
为什么你认为MongoDB更好？什么是访问此信息？您有使用MongoDB或ProgreSQL的经验吗？如果你这样做，我可能会建议你坚持使用你最熟悉的方法。另外，你希望存储的数据大小是多少？我们谈论的是数千、数百万或数十亿个元素和关系（行）？请查看Mongo的这篇文章，ProgreSQL的这篇文章：在最初的文章中添加了更多信息鉴于您所谈论的关于任何现代数据库的数据都非常少。我建议你试着用这两种方法进行试验，并选择似乎适合你的需要和技能的方法。我不知道你为什么不看图形数据库。