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

Question

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

在阅读了 5 个 DB（Postgrel、Mongo、Couch、Arango 和 Neo4J）之后，当我想到“……事物之间的关系比事物本身更重要”这句话时，我决定深入研究 OrientDB。 OrientDB的设计理念和创新特性（多模型、集群、OO、native graph、full graph API、SQL-like、LiveQuery、multi-masters、auditing、simple RID和version number ...）不断激起我的热情.

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

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

1. LINK 与 EDGE

以一个CLIENT可能会下数千个ORDER的案例，如何在LINKs和EDGEs之间进行选择来存储关系？我更喜欢 EDGE，但它们似乎会在 CLIENT 记录中存储数千个 ORDER 的 RID。

1. 嵌入记录的安全性

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

1. 创纪录的安全性

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

希望我表达清楚。任何话都将不胜感激。

Answer 1

LINK 与 EDGE

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

记录 - 级别安全

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

嵌入式记录的安全性

我做了这个例子来尝试回答你的问题

我有这个结构：

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

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

select from Car

更新

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

希望对你有帮助