The DyanmoDB [best practices](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html) make it clear that:

> You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.

I find it amusing then that just about every single tutorial I've seen dealing with DyanmoDB has a multi-table design.

But what does this mean in practice?

Let's consider a simple application with three main entities: Users, Projects, and Documents. A User owns multiple projects, and a Project can have multiple Documents. We typically have to query on the Projects for a User, and on the Documents for a Project. Reads outnumber writes by a significant margin.

A naive tutorial's table design would use three tables:

    Users
    Hash key
    user-id

    Projects
    Hash key       Global Index
    project-id     user-id

    Documents
    Hash key       Global Index
    document-id    project-id

We could pretty easily collapse `Project` and `Document` into one `Documents` table:


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

But why stop there? Why not one table to rule them all? Since the `User` is the root of everything...


    Users
    Hash key    Sort key
    user-id     aspect
    ---------   ---------
    foo         user                   email: [email protected] ...
    foo         project:1              title: "The Foo Project"
    foo         project:1:document:2   document-id: 2     ...

Then we would have a Global Index on, say, the `email` field for user record lookups, and another on the `document-id` field for direct document lookups.

Is that how it's supposed to work? Is it legit to throw such wildly-divergent kinds of data into the same table? Or is the second, two-table design a better approach? 

At what point is it legitimate to add a second table?