标签: index-design

DyanmoDB最佳实践明确指出：

您应该在 DynamoDB 应用程序中维护尽可能少的表。大多数设计良好的应用程序只需要一张表。

我觉得很有趣，我见过的处理 DyanmoDB 的几乎每个教程都有多表设计。

但这在实践中意味着什么？

让我们考虑一个具有三个主要实体的简单应用程序：用户、项目和文档。一个用户拥有多个项目，一个项目可以有多个文档。我们通常必须查询用户的项目和项目的文档。读取数量大大超过写入数量。

一个天真的教程的表格设计将使用三个表格：

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

我们可以很容易崩溃Project，并Document为一个Documents表：

Documents
Hash key    Sort key        Global Index
project-id  document-id     user-id

但为什么要停在那里？为什么不用一张桌子来统治他们呢？既然User是一切的根源...

Users
Hash key    Sort key
user-id     aspect
---------   ---------
foo         user                   email: foo@bar.com ...
foo         project:1              title: "The Foo Project"
foo         project:1:document:2   document-id: 2     ...

然后我们将有一个全局索引，例如，email用于用户记录查找的document-id字段，以及另一个用于直接文档查找的字段。 …

我正在尝试改进这个（子）查询作为更大查询的一部分：

select SUM(isnull(IP.Q, 0)) as Q, 
        IP.OPID 
    from IP
        inner join I
        on I.ID = IP.IID
    where 
        IP.Deleted=0 and
        (I.Status > 0 AND I.Status <= 19) 
    group by IP.OPID

Sentry Plan Explorer 指出了由上述查询执行的表 dbo.[I] 的一些相对昂贵的 Key Lookups。

表 dbo.I

    CREATE TABLE [dbo].[I] (
  [ID]  UNIQUEIDENTIFIER NOT NULL,
  [OID]  UNIQUEIDENTIFIER NOT NULL,
  []  UNIQUEIDENTIFIER NOT NULL,
  []  UNIQUEIDENTIFIER NOT NULL,
  [] UNIQUEIDENTIFIER NULL,
  []  UNIQUEIDENTIFIER NOT NULL,
  []  CHAR (3) NOT NULL,
  []  CHAR (3)  DEFAULT ('EUR') NOT NULL,
  []  DECIMAL …