我们正在为我们的创新“协作应用程序”寻找最合适的数据库。抱歉，我们不知道如何以通常理解的方式命名它。事实上，租户、角色、用户、任务和账单之间高度复杂的关系需要有效处理。
读完5个DB(Postgrel、Mongo、Couch、Arango和Neo4J)，当我眼前浮现“……事物之间的关系比事物本身更重要”这句话时，我下定决心要深入研究OrientDB。 OrientDB的设计理念和创新特性(多模型、集群、OO、原生图、全图API、类SQL、LiveQuery、多主、审计、简单RID和版本号...)不断增强我的热情.
OrientDB 启发我重新思考并尝试从完全不同的角度进行建模!
我们现在正在设计基于OrientDB的数据结构。但是，有一些问题让我困惑。
- LINK 与 EDGE
以客户可能下数千个订单为例，如何选择LINK和EDGE来存储关系？我更喜欢 EDGE，但它们似乎在 CLIENT 记录中存储了数千个订单 RID。
嵌入记录可以独立于其容器记录进行授权吗？
激活记录级安全性如何影响查询性能？
希望我表达清楚。任何言语都会受到真正的赞赏。
最佳答案
LINK 与 EDGE
如果您的拱门上没有属性，您可以使用链接，如果有，则可以使用边缘。如果您需要在两个方向上遍历关系，那么您确实需要边，而使用链接列表时您只能在一个方向上遍历(就像网络上的超链接一样)，而无需边的开销。如果您需要遍历图形，边是正确的选择。边比链接列表需要更多的存储空间。它们之间的另一个区别是，如果您有两个顶点通过链接 A --> (link) B 相互链接，那么如果删除 B，该链接不会消失，它会保留下来，但不会指向某些东西。之所以这样设计，是因为当您删除文档时，找到链接到该文档的所有其他文档将意味着对数据库进行全面扫描，这通常需要很长时间才能完成。具有双向链接的 Graph API 是专门为解决此问题而设计的，因此一般情况下我们建议客户使用它，或者小心并在应用程序级别管理链接一致性。
记录 - 安全级别
使用 100 万个顶点和一个名为 Luke 的管理员用户，执行如下查询:select from where title = ?使用 NOT_UNIQUE_HASH_INDEX 时，执行时间为 0.027 秒。 OrientDB有用户和角色的概念，以及记录级安全性。它还支持基于 token 的身份验证，因此可以使用 OrientDB 作为授权/验证用户的主要手段。
嵌入式记录的安全性
我制作这个示例是为了尝试回答您的问题
我有这样的结构:
如果我想访问嵌入的数据，我必须执行以下命令:select prop from User
因为如果我尝试通过包含汽车类型的类访问它，我将不会得到任何类型的结果
select from Car
更新
OrientDB 支持这种授权/身份验证，但它与您的示例有点不同。例如:如果用户A在没有管理员权限的情况下插入了一条记录，那么另一个用户B就看不到用户A在没有管理员权限的情况下插入的记录。用户只能看到已插入的记录。
希望对你有帮助
关于orientdb - 关于OrientDB设计的一些问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36957786/