The data model in DynamoDB can be expressed in three entities.

A DynamoDB table corresponds to a standard SQL database table. Each row (or data record) is referred to as an "item" in a table. Since DynamoDB is schema-less, each item can have different columns (attributes) or even have the same attribute that holds data of various types. For example, two items may have the attribute - "contact," where one item has data of type string while the other item has an array of strings.

Each record in DynamoDB is an item. DynamoDB allows users to store data up to 400KB per item. Additionally, these items do not need predefined attributes. But, each item must have a unique identifier called a partition key (or a composite partition key that combines a partition and sort key to create a different item).

The partition key helps DynamoDB find the partition to store the item. On top of that, the partition key helps DynamoDB reduce the data that needs to be queried by querying only the partition that holds the data item.

Every DynamoDB item must have one main attribute - Partition Key. Additionally, DynamoDB allows users to create an infinite number of custom attributes. These attributes can be data varying from types - string, number, maps, arrays, and booleans.

Also, an attribute does not have a defined data type. So, users can store different types of data under the same attribute name across multiple items.

Lastly, an attribute is not bounded by a maximum size limit. However, if you are persisting a map for an attribute, DynamoDB will only allow 32 levels of nesting.

Users are usually familiar with designing the database before discussing requirements. This is the traditional SQL approach because SQL offers the flexibility of querying with any attribute. However, in DynamoDB, it's crucial to identify the requirements first so that you can effectively select the Partition and Sort Keys for your table and indexes to help create the required access patterns.

Choosing the correct partition key is vital because this determines where the data will get stored. So, if you select a key with few distinct values (for example, a status with only three types: Good, Average, and Bad), your requests are not spread across many partitions. As a result, this can cause specific partitions to exhaust the RCU (3000), causing a Hot Partition that throttles and slows your application down.

DynamoDB does not support using JOIN queries mainly because JOIN queries do not scale well as a dataset grows. However, this does not mean DynamoDB cannot model relational data. For example, you can use a Single Table Design (store all application data in one table) to model relational data using generic Partition and Sort Keys effectively. To find out more, look at the article on Performing Joins in DynamoDB.

A helpful tip that many may find beneficial is the effective use of indexes on DynamoDB. Effectively using DynamoDB indexes (GSIs in particular) helps create Sparse Indexes. These Sparse Indexes can help create data groups that only match a specific condition. Then, when you need the data, you can query it using a smaller dataset via the GSI rather than querying the entire table for it.

Finally, always project attributes that you will be using in the index. If not, you will incur additional WCUs to keep the base table and indexes in sync.