这是一个关于最佳实践的问题，我知道有很多不同的选择可以做到这一点，但我想你的意见，你将如何解决这个问题。请将其视为在此系统中性能至关重要，换句话说，可扩展。
我最近发现了图形数据库的奇迹，所以我想出了一个公司想要管理它的客户关系的理论情况，为了做到这一点，他们将使用neo4j这是伟大的，并允许真的很棒的客户管理，不同的员工和他们的关系，这一切都很棒，但公司现在想要创建一个需要身份验证的基于Web的界面，neo4j数据库中的任何人都应该能够登录到系统为了了解它们与公司数据库中其他人的关系，因此每个用户必须拥有与其姓名相关联的密码/电子邮件/ ID。
所以我的问题是，在这种情况下，最好将password_hash / password_salt / id / email存储在mysql数据库中，然后根据节点在mysql数据库中查找它。或者将password_hash / password_salt / id / email存储在节点内的哈希表中更好。
此外，每个商店都有1000个产品，它们可以存储在图形数据库中，或者我可以将产品存储在mysql数据库中，然后在那里查找产品，并在那里进行更改，因为产品不相关彼此之间没有任何意义，将它们存储在图形数据库中，那么它们是否应该存储在那里以提高性能呢？
所以我的问题归结为：大型项目最好是使用图形数据库以及更常见的rdms数据库，例如mysql？如果没有，那么你开始使用这两个数据库系统的重点是什么？
由于我对数据库术语缺乏了解，所以提前道歉。答案 0 :(得分：11)
图形DB主要用于维护关系。如果app有一个图形数据库，并不意味着应用程序需要将所有内容存储在Graph DB中。
Graph上的每个节点请求都在内存中，因此如果您的节点中有不必要的属性，它将会变得臃肿，可能会使事情变得更慢并占用更多内存。我通常会决定需要在图表中添加什么以及需要进行哪些操作DB通过非常简单的规则。
高级属性（定义关系和定义节点的其他重要属性）在图中，而其他信息在RDMS中。
例如，在FB中可能是FBID，Name在Graph中定义，因为它定义了一个节点与另一个节点的关系。但是当用户点击某人的脸书ID时，他/她会看到其他用户DOB，年龄，大学。所有这些都可以进入RDBMS。
PS：RDMS还有另一个优势，它可以用于快速分析。我知道图表也可以这样做，但我不确定它是否像RDBMS一样可扩展和简单。
这种方法的缺点是：你需要维持两个星展银行。
答案 1 :(得分：3)
除非你有一个双DB解决方案的成熟案例，否则我会说更少的移动部件可以让你更敏捷，更能够快速改变事物。如果稍后您发现难以使用的用例，那么请权衡引入第二个存储的成本/收益。双DB架构并非闻所未闻，但却带来了开销。
特定于安全性，没有理由说Neo4j或任何其他合理的NOSQL解决方案无法做到这一点：http://spring.neo4j.org/docs#tutorial_security
答案 2 :(得分：1)
如果存在将数据存储在诸如neo4j / orientDB之类的图形数据库中没有多大意义的数据，你应该同时使用这两种数据（并且某些数据在图形数据库中会比关系数据库更好） 。在一个平台上强制数据可能会导致性能/可扩展性问题。