dynamodb-access-patterns

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

DynamoDB Access Patterns

DynamoDB访问模式

This skill guides an interactive conversation to extract, formalize, and persist all access patterns for a DynamoDB single-table design. It is language-agnostic and project-agnostic -- it works for any application regardless of tech stack.

本Skill通过交互式对话，帮助提取、规范化并留存DynamoDB单表设计的所有访问模式。它与语言无关且与项目无关——适用于任何技术栈的应用。

When to Use

使用场景

The user wants to design a new DynamoDB table from scratch
The user wants to add new entities to an existing DynamoDB table
The user says things like "I need to store X and query by Y"
The user wants to document their access patterns before implementation
The user has an existing relational schema they want to migrate to DynamoDB

用户想要从零开始设计新的DynamoDB表
用户想要向现有DynamoDB表中添加新实体
用户表达类似“我需要存储X并通过Y查询”的需求
用户想要在实现前记录访问模式
用户想要将现有关系型数据库架构迁移到DynamoDB

Pipeline Position

流程定位

  [1. Access Patterns]  -->  2. Table Design  -->  3. Query Interfaces
       (this skill)        (dynamodb-table-     (dynamodb-query-
                            design)              interfaces)

This skill produces a

.md

file that is consumed by

dynamodb-table-design

  [1. 访问模式]  -->  2. 表设计  -->  3. 查询接口
       (本Skill)        (dynamodb-table-     (dynamodb-query-
                            design)              interfaces)

本Skill生成的

.md

文件将被

dynamodb-table-design

Skill调用。

Interactive Workflow

交互式工作流

Step 1: Understand the Domain

步骤1：理解业务领域

Ask the user to describe their application at a high level. You need to understand:

What does the application do? (e-commerce, social network, game, SaaS, etc.)
Who are the actors? (users, admins, systems, etc.)
What are the main entities? (the "nouns" of the system)

Ask open-ended questions. Don't assume -- let the user describe their domain.

Example opening:

Before designing the DynamoDB table, I need to understand your domain.

1. What does your application do in one sentence?
2. What are the main entities (things you need to store)?
3. Who or what interacts with these entities?

请用户从宏观层面描述其应用。你需要了解：

应用的核心功能是什么？（电商、社交网络、游戏、SaaS等）
涉及哪些角色？（用户、管理员、系统等）
主要实体有哪些？（系统中的“名词”）

提出开放式问题，不要主观假设，让用户自行描述其业务领域。

示例开场：

在设计DynamoDB表之前，我需要先了解你的业务领域。

1. 用一句话描述你的应用功能是什么？
2. 需要存储的主要实体有哪些？
3. 哪些角色或系统会与这些实体交互？

Step 2: Catalog All Entities

步骤2：梳理所有实体

For each entity the user mentions, gather:

Field	Description	Example
Name	Singular name, PascalCase	`Order`
Description	What it represents	"A purchase made by a customer"
Attributes	All fields with types	`orderId: string, total: number, status: string, createdAt: datetime`
Relationships	How it relates to other entities	"Belongs to a User. Contains many OrderItems."
Cardinality	Expected volume	"~100 orders per user, ~10M total"
Lifecycle	Does it expire? Get updated? Deleted?	"Updated when status changes. Archived after 1 year."

Ask the user about EACH entity systematically. Don't skip attributes -- they affect key design later.

IMPORTANT: Also identify counter/aggregate entities that the user might not think of as entities:

"Do you need to track counts? (e.g., number of orders per user)"
"Do you need running totals or balances?"
"Do you need any metadata records?"

针对用户提到的每个实体，收集以下信息：

字段	描述	示例
名称	单数形式，采用PascalCase命名法	`Order`
描述	实体的含义	"客户发起的一笔订单"
属性	所有字段及其类型	`orderId: string, total: number, status: string, createdAt: datetime`
关联关系	与其他实体的关联方式	"属于某一User，包含多个OrderItem"
数据量级	预期的存储规模	"每个用户约100笔订单，总计约1000万笔"
生命周期	是否会过期？是否会更新？是否会被删除？	"状态变更时更新，1年后归档"

系统地询问用户每个实体的信息，不要遗漏属性——这些信息会影响后续的键设计。

重要提示：同时识别用户可能未意识到的计数器/聚合实体：

“你是否需要追踪统计数据？（例如，每个用户的订单数量）”
“你是否需要累计总额或余额数据？”
“你是否需要任何元数据记录？”

Step 3: Elicit Access Patterns

步骤3：梳理访问模式

This is the most critical step. For EACH entity, ask:

For [Entity], how will your application access this data?
Think about every screen, API endpoint, or background job that reads or writes this entity.

For each access pattern, capture these fields:

Field	Description
ID	Sequential number (AP-001, AP-002, ...)
Entity	Which entity or entities are involved
Operation	Read / Write / Update / Delete
Description	Plain English description
Input Parameters	What the caller provides
Result Type	Single item, Collection, or Count
Sort Required	None, Ascending, Descending -- and by what field
Filters	Any conditions beyond the lookup key
Pagination	Yes/No -- is the result set potentially large?
Frequency	Hot (>100/s), Warm (1-100/s), Cold (<1/s)
Consistency	Eventual (default) or Strong
Multi-Entity	Does this pattern need data from multiple entity types in one call?

Probing questions to uncover hidden patterns:

"How do you list these? All at once, paginated, or filtered?"
"Do you ever need to sort by anything other than creation time?"
"Do you need to look this up from the 'other side'?" (e.g., find user by email, not just by userId)
"Are there any leaderboards, rankings, or sorted lists?"
"Do you need to check existence before creating?"
"Are there any batch operations? (create 10 items at once)"
"Do any items have a TTL or expiration?"
"Do you need to fetch a parent AND its children in one call?"

这是最关键的步骤。针对每个实体，询问：

对于[实体]，你的应用将如何访问这些数据？
请考虑所有涉及该实体读写的页面、API接口或后台任务。

针对每个访问模式，记录以下字段：

字段	描述
ID	序号（AP-001、AP-002等）
实体	涉及的一个或多个实体
操作类型	读取/写入/更新/删除
描述	通俗易懂的文字说明
输入参数	调用方提供的参数
结果类型	单条数据、集合或计数
排序需求	无、升序、降序——以及按哪个字段排序
过滤条件	除查询键之外的其他条件
分页需求	是/否——结果集是否可能很大？
访问频率	高频（>100次/秒）、中频（1-100次/秒）、低频（<1次/秒）
一致性要求	最终一致性（默认）或强一致性
多实体关联	该模式是否需要在一次调用中获取多个实体类型的数据？

用于挖掘隐藏模式的追问问题：

“你如何列出这些数据？一次性全部列出、分页还是过滤？”
“除了创建时间之外，你是否需要按其他字段排序？”
“你是否需要从‘反向’查询？”（例如，通过邮箱而非userId查找用户）
“是否涉及排行榜、排名或排序列表？”
“创建数据前是否需要检查其是否已存在？”
“是否存在批量操作？（例如，一次性创建10条数据）”
“是否有数据设置了TTL（生存时间）或自动过期？”
“是否需要在一次调用中同时获取父实体及其子实体？”

Step 4: Identify Item Collection Opportunities

步骤4：识别项集合优化机会

Review all access patterns and look for cases where multiple entity types are fetched together. These are the most valuable patterns in single-table design.

Ask the user:

Looking at your access patterns, I see some opportunities to fetch related data in a single query:

- [AP-003] and [AP-007] both need User + Orders data
- [AP-012] needs Product + Reviews together

Do these always get fetched together, or only sometimes?
Are there screens/endpoints where you need BOTH in one call?

Mark these patterns explicitly as item collection candidates.

回顾所有访问模式，寻找需要同时获取多个实体类型数据的场景。这些是单表设计中最有价值的模式。

询问用户：

查看你的访问模式后，我发现一些可以在单次查询中获取关联数据的机会：

- [AP-003]和[AP-007]都需要User + Orders数据
- [AP-012]需要同时获取Product + Reviews数据

这些数据是否总是需要一起获取，还是仅在某些场景下需要？
是否有页面或接口需要在一次调用中获取这两类数据？

将这些模式明确标记为项集合候选。

Step 5: Identify Write Patterns and Transactions

步骤5：识别写入模式与事务需求

For every write operation, determine:

How many items are written per operation? (single item vs. transaction)
Must they succeed or fail together? (transaction requirement)
Are there conditional writes? (don't overwrite if exists, ensure parent exists, etc.)
Do writes affect counters? (incrementing a count alongside creating an item)

Example questions:

When you create an Order:
- Do you also need to update the user's order count?
- Do you need to add it to a global "recent orders" list?
- Should it fail if the user doesn't exist?

针对每个写入操作，确定：

每次操作需要写入多少条数据？（单条数据 vs 事务）
这些操作是否必须同时成功或失败？（事务需求）
是否存在条件写入？（例如，数据已存在则不覆盖、确保父实体存在等）
写入操作是否会影响计数器？（例如，创建数据的同时递增计数）

示例问题：

当你创建Order时：
- 是否需要同时更新用户的订单计数？
- 是否需要将其添加到全局“最新订单”列表中？
- 如果用户不存在，创建操作是否应该失败？

Step 6: Validate Completeness

步骤6：验证完整性

Before persisting, do a final review with the user:

Here's a summary of what I've captured:

Entities: [list]
Access Patterns: [count] total
  - Reads: [count]
  - Writes: [count]
  - Multi-entity: [count]

Missing anything? Common things people forget:
- Admin/backoffice access patterns
- Search/filtering patterns
- Reporting or analytics queries (these may go to a different system)
- Migration or bulk import patterns
- Audit trail / history patterns

在留存数据前，与用户进行最终核对：

以下是我已梳理的内容总结：

实体列表：[列表]
访问模式总数：[数量]
  - 读取操作：[数量]
  - 写入操作：[数量]
  - 多实体关联：[数量]

是否有遗漏？常见的遗漏场景包括：
- 管理员/后台系统的访问模式
- 搜索/过滤模式
- 报表或分析查询（这些可能会走其他系统）
- 迁移或批量导入模式
- 审计追踪/历史记录模式

Output Format

输出格式

Persist the output as a markdown file. The user chooses the path, but suggest

docs/dynamodb/access-patterns.md

or a similar location in their project.

Read
reference/output-template.md
for the exact file structure to use.

将输出内容保存为Markdown文件。用户可自定义文件路径，建议存放在项目中的

docs/dynamodb/access-patterns.md

或类似位置。

请参考
reference/output-template.md
获取具体的文件结构。

Rules for the Agent

Agent规则

Never skip the interactive conversation. Don't generate access patterns from assumptions. Always ask.
Be thorough. It's better to capture 5 patterns you don't use than miss 1 you need.
Challenge the user. If they say "I just need basic CRUD", push back with specific questions about sorting, filtering, pagination, and multi-entity reads.
Stay language-agnostic. Use generic types:
```
string
```
,
```
number
```
,
```
boolean
```
,
```
datetime
```
,
```
list
```
,
```
map
```
. Don't use TypeScript, Python, or Java-specific types.
Don't design keys yet. This skill is about WHAT data you need, not HOW to store it. Key design happens in the next skill (
```
dynamodb-table-design
```
).
Persist the file. Always write the output to a
```
.md
```
file. This file is the input for the next step.
Use the question tool. When you need to clarify between options, use the interactive question tool to give the user clear choices.
Number everything. Access patterns must have stable IDs (AP-001, AP-002, ...) because the next skill references them.
Mark multi-entity patterns explicitly. These are the most important patterns for single-table design.
Include write patterns. Writes determine transactions and item duplication strategy. They're as important as reads.

绝不跳过交互式对话。不要主观假设生成访问模式，一定要向用户确认。
确保全面性。多记录5个用不上的模式，也比遗漏1个必需的模式要好。
主动质疑用户。如果用户说“我只需要基础的CRUD操作”，要进一步追问排序、过滤、分页和多实体读取的具体需求。
保持与语言无关。使用通用类型：
```
string
```
、
```
number
```
、
```
boolean
```
、
```
datetime
```
、
```
list
```
、
```
map
```
。不要使用TypeScript、Python或Java等特定语言的类型。
暂不设计键。本Skill关注的是你需要什么数据，而非如何存储。键设计将在下一步的
```
dynamodb-table-design
```
Skill中完成。
务必留存文件。始终将输出内容写入
```
.md
```
文件，该文件是下一步流程的输入。
使用提问工具。当需要在多个选项间确认时，使用交互式提问工具为用户提供清晰的选择。
所有内容编号。访问模式必须使用稳定的ID（AP-001、AP-002等），因为下一步的Skill会引用这些ID。
明确标记多实体模式。这些是单表设计中最重要的模式。
包含写入模式。写入操作决定了事务策略和数据复用方式，其重要性与读取操作相当。

Next Step

下一步

Once the access patterns file is complete, tell the user:

Access patterns are documented at [file path].

The next step is to design the DynamoDB table structure -- partition keys,
sort keys, GSIs, and map each access pattern to a concrete DynamoDB operation.

To continue, use the `dynamodb-table-design` skill with this file as input.

当访问模式文件完成后，告知用户：

访问模式已记录在[文件路径]。

下一步是设计DynamoDB表结构——分区键、排序键、GSI，并将每个访问模式映射为具体的DynamoDB操作。

如需继续，请使用`dynamodb-table-design` Skill，并将本文件作为输入。