この記事でわかること

前提：DynamoDB設計で一番大事なこと

DynamoDBは、RDBのように「テーブル構造を決めてからクエリを書く」設計思想ではなく、
「どう取得するか（アクセスパターン）」を先に決めてから、キー設計（PK/SK）へ落とすのが推奨される。

DynamoDBでは以下が「後から簡単には変えられない」要素になる。

したがって、設計の最初に「どんな取得が必要か」を言語化しないと、
後工程で Scan に寄ったり、破壊的変更（テーブル作り直し）になりやすい。

この記事では 1〜2 を扱う。

最初はDBのことを忘れて「何が欲しいか」を列挙する。

例（ユーザーと投稿があるサービス）：

ポイント：
ここでは「どうやって取るか」ではなく「何を取るか」だけを書く

ユースケースを「DBアクセス」として具体化する（取得条件・並び順・件数）。

例：

No	アクセス内容	取得条件	並び順	想定件数	備考
1	ユーザーをIDで取得	userId	-	1	GetItem想定
2	ユーザー一覧取得	-	createdAt（降順）	10〜100	Query想定
3	ユーザーの投稿一覧	userId	createdAt（降順）	数十	Query想定
4	ユーザーの最新投稿取得	userId	createdAt（降順）	1	Query + Limit
5	投稿をIDで取得	postId	-	1	GetItem想定

アクセスパターンを洗い出す段階で、ざっくり以下を意識するとブレにくい。

この時点で、一覧が多いなら「Query前提のキー設計」が必要だと判断できる。

以下をそのまま貼り付けて使う。

No	ユースケース	API/画面	取得条件	フィルタ条件	並び順	想定件数	更新頻度	一貫性要件	優先度	備考
1	ユーザー詳細	GET /users/{id}	userId	-	-	1	中	強/結果整合	高	GetItem想定
2	ユーザー一覧	GET /users	-	status=active	createdAt（降順）	10〜100	低	結果整合	中	Query想定
3	投稿一覧	GET /users/{id}/posts	userId	-	createdAt（降順）	数十	中	結果整合	高	Query + SK時系列
4	最新投稿	GET /users/{id}/posts/latest	userId	-	createdAt（降順）	1	中	結果整合	中	Query + Limit=1
5	投稿詳細	GET /posts/{id}	postId	-	-	1	中	強/結果整合	高	GetItem想定

対策：まず「確実に必要なアクセス」を優先度つきで固め、後から増えるものは段階的に対応する。

※段階的対応の典型：