关系型数据库：工具与规则
操作 CloudBase 关系型数据库的工具和规则
如何使用
查看如何使用提示词了解详细的使用方法。
测试提示词
你可以使用以下提示词来测试：
- "帮我创建一个用户表并设置权限"
- "执行 SQL 查询和更新操作"
提示词
rule.md
## When to use this skill
Use this skill when an **agent** needs to operate on **CloudBase Relational Database via MCP tools**, for example:
- Inspecting or querying data in tables
- Modifying data or schema (INSERT/UPDATE/DELETE/DDL)
- Reading or changing table security rules
Do **NOT** use this skill for:
- Building Web or Node.js applications that talk to CloudBase Relational Database (use the Web/Node Relational Database skills)
- Auth flows or user identity (use the Auth skills)
## How to use this skill (for a coding agent)
1. **Recognize MCP context**
- If you can call tools like `executeReadOnlySQL`, `executeWriteSQL`, `readSecurityRule`, `writeSecurityRule`, you are in MCP context.
- In this context, **never initialize SDKs for CloudBase Relational Database**; use MCP tools instead.
2. **Pick the right tool for the job**
- Reads → `executeReadOnlySQL`
- Writes/DDL → `executeWriteSQL`
- Inspect rules → `readSecurityRule`
- Change rules → `writeSecurityRule`
3. **Always be explicit about safety**
- Before destructive operations (DELETE, DROP, etc.), summarize what you are about to run and why.
- Prefer running read-only SELECTs first to verify assumptions.
---
## Available MCP tools (CloudBase Relational Database)
These tools are the **only** supported way to interact with CloudBase Relational Database via MCP:
### 1. `executeReadOnlySQL`
- **Purpose:** Run `SELECT` queries (read-only).
- **Use for:**
- Listing rows, aggregations, joins.
- Inspecting data before changing it.
**Example call (conceptual):**
```sql
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC LIMIT 50;
```
Call this through the MCP tool instead of embedding SQL in code.
### 2. `executeWriteSQL`
- **Purpose:** Run **write or DDL** statements:
- `INSERT`, `UPDATE`, `DELETE`
- `CREATE TABLE`, `ALTER TABLE`, `DROP TABLE`
- **Use for:**
- Data migrations
- Fixing or seeding data
- Schema changes
**Important:** When creating a new table, you **must** include the `_openid` column for per-user access control:
```sql
_openid VARCHAR(64) DEFAULT '' NOT NULL
```
Before calling this tool, **confirm**:
- The target tables and conditions are correct.
- You have run a corresponding `SELECT` via `executeReadOnlySQL` when appropriate.
### 3. `readSecurityRule`
- **Purpose:** Read security rules for a given table.
- **Use for:**
- Understanding who can read/write a table.
- Auditing permissions on sensitive tables.
Security rule types typically include:
- `READONLY` – anyone can read, no one can write
- `PRIVATE` – only authenticated users can read/write
- `ADMINWRITE` – anyone can read, only admins can write
- `ADMINONLY` – only admins can read/write
- `CUSTOM` – custom security logic
### 4. `writeSecurityRule`
- **Purpose:** Set or update security rules for a table.
- **Use for:**
- Hardening access to sensitive data
- Opening up read access while restricting writes
- Applying custom rules when needed
When using this tool:
- Clearly explain the **intent** (who should read/write what).
- Prefer standard rule types (`READONLY`, `PRIVATE`, etc.) before `CUSTOM`.
---
## Scenario 1: Safely inspect data in a table
1. Use `executeReadOnlySQL` with a limited `SELECT`:
- Include a `LIMIT` clause.
- Filter by relevant conditions.
2. Review the result set and confirm it matches expectations.
This pattern prevents accidental full-table scans and gives you context before any write operations.
---
## Scenario 2: Apply a schema change
1. Use `executeReadOnlySQL` to inspect the current schema or data (if needed).
2. Plan the `CREATE TABLE` / `ALTER TABLE` statement.
3. Run it once via `executeWriteSQL`.
4. Optionally, validate by running `SELECT` again.
Always describe:
- What schema change you are making.
- Why it is safe in the current context.
---
## Scenario 3: Tighten security rules on a sensitive table
1. Call `readSecurityRule` for the table to see current settings.
2. Decide on the target rule (e.g., from `READONLY` → `PRIVATE`).
3. Explain the change and why it matches the user’s requirements.
4. Call `writeSecurityRule` with the new rule.
5. Optionally, re-read the rule to confirm the update.
---
## Key principle: MCP tools vs SDKs
- **MCP tools** are for **agent operations** and **database management**:
- Run ad-hoc SQL.
- Inspect and change security rules.
- Do not depend on application auth state.
- **SDKs** are for **application code**:
- Frontend Web apps → Web Relational Database skill.
- Backend Node apps → Node Relational Database quickstart.
When working as an MCP agent, **always prefer these MCP tools** for CloudBase Relational Database, and avoid mixing them with SDK initialization in the same flow.