join - 自连接 documentdb 语法错误

Question

我在对 documentdb 执行 SQL 有效的自连接查询时遇到问题。

所以下面的查询有效:SELECT * FROM c AS c1 WHERE c1.obj="car"

但是这个简单的自连接查询不会:SELECT c1.url FROM c AS c1 JOIN c AS c2 WHERE c1.obj="car"AND c2.obj="person"AND c1.url = c2。 url，出现错误，Identifier 'c' could not be resolved。

It seems documendb 支持文档内的自连接，但我在集合级别询问。

我看官方syntax doc并了解集合名称基本上是推断出来的；我尝试将 c 显式更改为我的集合名称和根目录，但均无效。

我是否遗漏了一些明显的东西？谢谢!

Answer 1

有几点需要澄清:

1.) 关于Identifier 'c' could not be resolved

查询仅限于单个集合；在上面的示例中，c是正在重新别名为 c1 的集合的隐式别名与 AS关键字。

您可以修复示例查询，更改修复 JOIN 以引用 c1 :

SELECT c1.url
FROM c AS c1
JOIN c1 AS c2
WHERE c1.obj="car" AND c2.obj="person" AND c1.url = c2.url`

这也等同于:

SELECT c1.url
FROM c1
JOIN c1 AS c2
WHERE c1.obj="car" AND c2.obj="person" AND c1.url = c2.url`

2.) 了解 JOIN 并检查您的数据模型

话虽如此，我认为修复上述查询语法问题不会产生您期望的行为。 JOIN DocumentDB SQL 中的关键字旨在与文档中的非规范化元素数组形成叉积(而不是在同一集合中的其他文档之间形成叉积)。如果您在这里遇到困难，可能值得退后一步，重新审视如何为 Azure Cosmos DB 建模数据。

在 RDBMS 中，您被训练为以实体为先并根据实体规范化数据模型。您严重依赖查询引擎来优化查询以适应您的工作负载(这通常可以很好地检索数据，但并不总是最佳的)。这里的挑战是，随着规模的增加，许多关系优势会消失，并且扩展到多个分片/分区成为一项要求。

对于像 Cosmos DB 这样的横向扩展分布式数据库，您需要首先了解工作负载并优化您的数据模型以适应工作负载(而不是首先考虑实体)。您需要记住，集合只是一个逻辑抽象，由分区集中的许多副本组成。它们不强制执行架构，并且是查询的边界。

在设计模型时，您需要将以下问题纳入您的思考过程:

• 就更广泛的解决方案而言，规模和吞吐量的规模是多少(数量级的估计就足够了)？

• 读取与写入的比率是多少？

• 对于写入 - 写入的模式是什么？主要是插入，还是有很多更新？

• 对于读取 - 前 N 个查询是什么样的？

以上内容会影响您对分区键的选择以及您的数据/对象模型的外观。例如:

• 请求的比率将有助于指导您如何进行权衡(使用帕累托原则并针对您的大部分工作负载进行优化)。
• 对于读取密集型工作负载，通常过滤的属性成为选择分区键的候选对象。
• 倾向于经常一起更新的属性应该在数据模型中一起抽象，远离以较慢节奏更新的属性(以降低更新的 RU 费用)。
• 不要害怕跨不同记录类型复制属性以增强可查询性和注释类型。例如，我们有两种类型的文档:cat 和 person。

    {
       "id": "Andrew",
       "type": "Person",
       "familyId": "Liu",
       "employer": "Microsoft"
    }
     
    {
       "id": "Ralph",
       "type": "Cat",
       "familyId": "Liu",
       "fur": {
             "length": "short",
             "color": "brown"
       }
    }
     

我们可以在不需要 JOIN 的情况下查询这两种类型的文档只需运行一个没有类型过滤器的查询:

SELECT * FROM c WHERE c.familyId = "Liu"

如果我们想过滤 type = “Person”，我们可以简单地在我们的查询中添加一个 type 过滤器:

SELECT * FROM c WHERE c.familyId = "Liu" AND c.type = "Person"