我正在开发一个使用关系数据库和图形数据库（sqlite和neo4j）的应用程序。我试图看看我是否能够摆脱sqlite只使用neo4j，我遇到了冗余问题。
假设我有表示音轨的节点。我想存储每个音轨的音乐类型。有数十万个节点，我不认为重复＆＃34;南非Psytrance＆＃34; 作为字符串属性是一个好主意，我很确定创建一个＆＃34;南非Psytrance＆＃34; 节点并将其链接到所有相关节点是一个更糟糕的想法（瓶颈？）。
如果我说使用 1）属性占用太多空间，并且使用 2）关系对于这个特定问题是一个糟糕的设计，我是对的吗？
当前代码使用sqlite db来存储一组音乐流派，并将它们的索引作为节点中的属性（在应用程序层中转换为它们的字符串表示形式）。
有没有办法只使用neo4j并避免瓶颈和冗余？
答案 0 :(得分：2)
选项1绝对不是要走的路，因为它会浪费空间，与良好的图形数据库设计是对立的。
选项2是使用图表DB执行此操作的经典方法。有许多neo4j数据库的例子，每个节点有很多关系。 neo4j目前支持DB中最多34 billion个关系，因此您将超出容量限制的危险性很小。所以，我建议你至少尝试使用这种方法。
还有一些关于使用neo4j存储类似数据的人的博客。例如：
[EDITED]
正如@Pawamoy提到的幻灯片所暗示的那样，实际上有第三种选择。也就是说，您可以为每个类型创建特定的节点标签，并将适当的类型标签（一个节点可以有多个）应用于每个轨道节点。这样可以避免使用类型的关系。然而，它往往会使标签空间“混乱”，因为标签至少感觉像“节点类型”，而“音乐类型”不是“专辑曲目”。此外，neo4j支持每个节点very limited number个标签，并且DB中的最大标签数也相对较小。所以，我不会使用这种方法，除非这样做有明确的优势，容量限制不是问题。