I. First, the Failure Cases: Three Common Ways Things Go Wrong

I've stepped in these pits myself. The first time I used AI to design a database table structure, I threw a one-line requirement at it: "Help me design the table structure for an e-commerce order system." The AI was very cooperative, spitting out a pile of CREATE TABLE statements—complete fields, tidy comments. I copied them straight into the database, it ran fine, and I was satisfied.

Three weeks later, the problems came:

Failure 1: Assumed field types. The order amount used float, causing precision loss during reconciliation; phone numbers were stored as int, and leading zeros simply vanished. I hadn't reviewed a single line of what the AI generated.

Failure 2: Missing business constraints. The user table had no soft-delete flag. Someone deleted a record in the test environment, and all the associated orders became orphan records. The AI didn't know my business had a compliance requirement that "data must be retained for 180 days after account cancellation"—because I never told it.

Failure 3: Letting the AI deliver everything in one shot, with no adversarial review. Once I asked the AI to "optimize" a table structure, and it suggested merging the order detail table into the order main table, on the grounds that "fewer JOINs improve performance." I followed its advice. Later, when an order needed to support split-package shipping, changing that master-detail structure was pure agony.

The common thread in these three approaches: treating AI as a code generator rather than a design partner. Independent developers and small teams fall into this trap most easily—short-handed, they want AI to finish everything in one go, skipping the most critical step: review.

II. The Right Approach: AI as Designer, and More Importantly, as Red Team

Later I adjusted my workflow. The core idea: AI proposes the design first, then AI plays red team to poke holes in it, and finally a human makes the call. The whole process has four steps.

Step 1: Feed It Context, Not Just Requirements

Don't just give a one-line requirement—explain the business background, data scale, and special constraints together. For example, I tell the AI: this is a SaaS for independent developers, single-tenant data volume expected at the hundred-thousand level, user phone numbers need to support international formats, and historical data must not be physically deleted.

Step 2: Have the AI Output a Design Document, Not SQL

I explicitly ask the AI not to write DDL yet, but to output a field list, reasons for each type, index design rationale, and identified business boundaries. The benefit: it's easier to spot logical problems in a document than in SQL, and it forces the AI to "explain itself"—the places it can't explain are often exactly where the pitfalls are.

Step 3: Open a New Conversation and Have the AI Play the Reviewer

This is the highest-ROI step in the entire process. Open a brand-new conversation (to avoid the AI favoring its own proposal), paste in the design document, and have it play a "nitpicking DBA," specifically hunting for: type pitfalls, index misuse, scalability risks, and overlooked business scenarios. AI versus AI often digs up problems I'd never think of myself—for example, it once reminded me that "if you plan to do monthly archiving later, the primary key should ideally carry time semantics." Details like that are hard to cover comprehensively on my own.

Step 4: Human Makes the Final Call, Then Generate SQL

After organizing the review feedback, I decide which suggestions to adopt. Only then do I have the AI output commented DDL and ER diagram documentation. At that point, the SQL is just a natural end product.

III. A Reusable Prompt Template

This is the review prompt template I've refined. Copy it, adjust the requirements, and it's ready to use:

你是一位有10年经验的后端架构师兼DBA,现在负责评审一份MySQL表结构设计。

【业务背景】
- 系统类型:(如:面向小团队的工单管理系统)
- 预估数据量:(如:单表百万级以内,增长缓慢)
- 特殊约束:(如:数据需软删除;需支持多时区;手机号含国际格式)

【待评审的设计方案】
(在此粘贴字段清单/设计文档/DDL)

【评审要求】
请从以下维度逐项挑刺,按严重程度排序输出:
1. 字段类型与长度是否合理(重点检查金额、手机号、时间戳、枚举值)
2. 主键与索引设计是否存在隐患(含写入放大、索引失效场景)
3. 业务边界遗漏:哪些真实场景下这套结构会出问题?
4. 扩展性风险:半年后如果新增XX需求,哪里会最先崩?
5. 给出修改建议,每条注明理由和改动的代价。

不要客套,直接指出问题;如方案整体可行,也要列出最值得警惕的前三个风险点。

The prompt for the design phase is similar—just replace the "评审要求" section with "First output the field list, type rationale, index approach, and business boundary list; do not generate SQL yet."

III. Before and After Using AI

Process time: Designing a ticketing system with ten tables by hand used to take about a day of research and diagramming; with this workflow, design plus review takes two or three hours, and the quality is higher.

Rework cost: Previously, letting AI generate SQL directly meant an average of two or three rounds of table-structure rework per project; after introducing "AI red-team review," structural rework after launch has essentially disappeared—problems get caught on paper.

Cognitive gains: This is the most easily overlooked benefit. The AI's review feedback explains its reasoning—for example, why decimal is better than float for money, or why soft deletes need a workaround with unique indexes. After reading enough of these explanations, my own design judgment has improved too. For independent developers, it's like hiring an always-online senior DBA as a mentor at low cost.

Cost: A full run of this process consumes roughly tens of thousands to over a hundred thousand tokens; the actual cost depends on the model you use—check the official pricing page. Compared to the rework time saved, this investment is negligible.

IV. A Few Reminders

1. AI review is no substitute for real load testing. Whether an index actually works ultimately comes down to execution plans and real data.
2. Don't paste confidential data directly. Sanitize table names and field semantics before feeding them to the AI.
3. Always make important decisions yourself. What AI gives you is a list of candidate options and risks, not an imperial decree.

On tooling: this workflow has certain requirements for model capability—the reasoning quality in the design phase directly determines the ceiling of the proposal, while the review phase depends more on whether the model can "avoid just agreeing with you." If you're looking for a stable model API channel, check out https://api.thistoken.ai/register —sign up and use it right away, well suited for making this design-review workflow a daily habit.

Table structure is the foundation of a system. Getting AI to draw diagrams is easy; getting AI to help you vet the foundation—that's where it truly earns its keep.

---

Tired of juggling provider integrations? Register at https://api.thistoken.ai/register and call every model through one base_url.