# The DynamoDB Book

Good question, Rob.  Obviously I can't speak for Alex DeBrie but it seems like for this demo example the schema is assuming that OrderItems don't come from anywhere, i.e. they only exist on an order.

Hey Rob, good question. The main point I was trying to show there was that the one-to-many pattern of 'Fetch Order and Order Items' would be handled in the secondary index. Thus, the primary key pattern in the base table was less important.

The second pattern you showed wouldn't have worked because it wouldn't have had enough uniqueness. In this model, the ItemId is an identifier for that particular item. If the PK & SK were both ITEM#<ItemId>, then the item would have been overwritten whenever *anyone* purchased that item in an order.

The first pattern (OrderId as PK, ItemId as SK) would have worked. That said, I generally avoid putting items in the same item collection unless I'm going to be fetching them as part of a Query. By spreading them and putting them into their own item collection based on the combination of OrderId and ItemId, you give DynamoDB the ability to really spread those out. It probably doesn't matter too much here, but just a practice I try to do.

Also, in this use-case you switch from originally using `MESSAGES#<Username>` for the PK, to `MESSAGE#{message.username}` for the PK in the code samples - was that (dropping the `S` off `MESSAGES`) intentional, or just a typo?

Nope, no particularly reason on the string vs. bool. I rarely think of the bool type, and I'll need to convert it from a string value ('true') no matter which DynamoDB type it is.

And nice catch on the MESSAGE/MESSAGES part! That's an error on my end. Will update :)

Good question, Martin, and it's one I keep seeing. Clearly someone needs to write the definitive post on it :)

I've opined briefly here. Basically, I think GraphQL & AppSync are optimizing for different things: frontend developer happiness and ease of backend code. As part of that, they'll accepting some inefficiencies in database access by having a single request make multiple hits to the database.

It's hard to say what the right approach is. I've gotten to where I say it's fine to use multiple tables with GraphQL & AppSync as long as you know and accept the tradeoffs.

There have been a few people (Rich Buggy) that have discussed using single-table design with GraphQL. And that's doable too! At that point, you're making a different tradeoff: more backend complexity in exchange for fewer database hits.

Martin you're not wrong. Amplify is nice but it seems like it is abstracting too much away. The documentation around the REST api with a DDB backend is severely lacking and seems very much about having a single hash key and distinct values. In fact if you use a hash and range key, it's not very clear what the url pattern should be to fetch a single item: /path/object/hash/range

I am working through a react/redux course right now so it is what it is, but I think when I'm done with this I'm going to work in a more lightweight version of amplify to serve my own sadistic desires to put my data in a single table.

If anyone is interested I'd be happy to post back here if anyone would like to help.

Thanks for posting, I hadn't read that page before.  Their suggestion to prefix the sort key with a version seems similar to suffixing the sort key with a date/version, as Alex suggested.

I don't think I like the prefix pattern because it seems more complicated, especially when adding a new item.  It looks like finding the next version number would mean using a queryfilter on all versions, and that gets messy if there are a lot of items or multiple versioned sort key patterns.

Owain, back in December I created a github repo for DynamoDB Single Table Models (https://github.com/deploystudios/dynamodb-single-table-models). I was on my post-reinvent/houlihan buzz and then holidays, life, etc.

The idea here was to create models that could be imported into NoSQL Workbench. Would like to extend this to include Dynobase as well. I figured it would be great to show different models for things like a CMS, IoT data, etc.

Alex DeBrie forgot I gave you a shout out on that page as well! Let me know if you'd like to use this.

Good thought, Owain . Let me see if I can clean these up and make them available.

My models are a bit spread out, to be honest. I often only want to show a subset of the data (e.g. Repos and Issues, or Deals and Categories), so I end up having ~10 different 'tables' in each model that I have. It made it easier to snapshot particular portions for the book.

Good question, and filtered streams are on my DynamoDB Wish List :).

That said, it turns out to be a pretty small detail in implementation to the point that I don't think we'll get it from the DDB team soon. In your stream handler, you can filter for the particular type of item you want and operate on it as needed. For events that don't match, just drop them and move on.

The biggest downside is that it can bundle a bunch of logic into one function if you are operating on a few different types of events. However, you usually just put the actual logic in separate modules and then have a top-level router that filters and places the events as needed.

I have a generic lambda that simply reads the stream, filters stuff out you are not interested in and then publishes the event onto a SNS topic (or Event Bridge) with some messageAttributes so you can set a lambda filterPolicy for subsequent Lambdas to listen in for.  A pub/sub pattern.

I parse the PK for the entityType (single table model and use the # as the delimiter) and set this as the messageType.  

messageType in the format: com.example.<entity_type>.<eventName>

I prefer to use POST, PUT and DELETE translated from eventName  ( INSERT | MODIFY | REMOVE ) but that's just me.

I also set a messageId from the eventId so we have a form of correlation id for logs.

The messageType is done in a reverse format so that it is easy to use a prefix on the filterPolicy (e.g. listen for all USER events).  

I also have other components in most of my PKs so I also set other message attributes which the rest of the architecture (multi-tenanted) uses.  e.g. you can  filter the subscription to pick up "all updates to users for a particular customer" .  
I do this since I use Appsync which directly does the DB write without setting some of the headers I need.  Hence they are encoded in the key.

If you're using EventBridge, it can subscribe to a dynamo stream and only invoke your lambda(s) with matching events.

Great question, Jędrzej. The short answer is to use what feels comfortable to you.

I use the pattern of two relational access patterns in a single item collection without hesitation, because it doesn't feel that complicated to me. The combination of a parent item and its related items in one item collection feels natural. And because I'm used to do it in one direction, I usually don't hesitate to use it in the other direction.

The maintenance cost feels low because it's usually a 'set it and forget it' situation. After you model out the entities and their access patterns, you write the logic one time to add the indexing attributes and the access patterns, then rarely touch it again. If you do add new entities, you need to make sure not to step on existing item collections, but you can usually see this from the entity chart.

That said, I know it is a burden. For me, I probably wouldn't use the strategy in Section 14.6 (Faking ascending order) very often. I find that one quite confusing. I wanted to show it as an example of what's possible, but it crosses the legibility barrier for me.

If two relationships in one item collection seems too much for you, then I'd advise to add an additional index. It may cost a bit more, but it could save you some time in future modeling.

Curious to hear what others think as well :)