关于在OrientDB上设计的一些问题

Question

我们正在为我们创新的“协作应用程序”寻找最合适的数据库。对不起，我们不知道如何以一般理解的方式命名。事实上，租户，角色，用户，任务和账单之间的高度复杂的关系需要得到有效处理。

在阅读了5个DB（Postgrel，Mongo，Couch，Arango和Neo4J）之后，当我看到“......事物之间的关系比事物本身更重要”时，我决定深入研究OrientDB。 OrientDB的设计理念和创新功能（多模型，集群，OO，原生图，完整图形API，类SQL，LiveQuery，多主机，审计，简单RID和版本号......）不断激发我的热情

OrientDB启发我重新思考并尝试从完全不同的角度进行建模！

我们现在正在设计基于OrientDB的数据结构。但是，有些问题让我感到困惑。

1. LINK vs. EDGE

假设客户可以放置数千个ORDER，如何在LINK和EDGE之间进行选择以存储关系？我更喜欢EDGE，但他们似乎在CLIENT记录中存储了数千个ORID的RID。

1. 嵌入式记录的安全性

嵌入式记录可以独立于其容器记录进行授权吗？

1. 记录级安全性

激活记录级安全性如何影响查询性能？

希望我表达清楚。任何言语都将得到真正的赞赏。

Answer 1

LINK vs EDGE

如果您的拱门上没有属性，则可以使用链接，而不是使用边缘。如果你需要在两个方向上遍历关系，你真的需要边缘，而使用链接列表只能在一个方向上（就像网络上的超链接一样），没有边缘的开销。如果您需要通过图形走路，边缘是正确的选择。标记需要比链接列表更多的存储空间。它们之间的另一个区别是，如果你有两个顶点通过链接A相互链接 - >＆gt; （链接）B如果你删除B，链接不会消失它会保留但没有指向某事。它是这样设计的，因为当您删除文档时，查找链接到它的所有其他文档将意味着对数据库进行全面扫描，这通常需要很长时间才能完成。带有双向链接的Graph API专门用于解决此问题，因此通常我们建议客户使用它，或者在应用程序级别小心并管理链接一致性。

记录 - 级别安全

使用1百万个顶点和一个名为Luke的管理员用户，进行如下查询：select from where title =？使用NOT_UNIQUE_HASH_INDEX执行时间为0.027秒。 OrientDB具有用户和角色的概念，以及记录级安全性。它还支持基于令牌的身份验证，因此可以使用OrientDB作为授权/验证用户的主要方式。

嵌入式记录的安全性

我试图回答你的问题时做了这个例子

我有这个结构：

如果我想访问嵌入数据，我必须执行以下命令：select prop from User

因为如果我尝试通过包含汽车类型的类来访问它，我将不会有任何类型的结果

select from Car

<强>更新

OrientDB支持这种授权/身份验证，但它与您的示例略有不同。例如：如果没有管理员权限的用户A插入记录，则另一个用户B无法在没有管理员权限的情况下看到用户A插入的记录。用户只能看到已插入的记录。

希望有所帮助