The Indie Developer's Old Habit: Designing Table Structures by Gut Feeling

If you're an indie developer or part of a small team of three to five people, this scenario has probably happened to you:

You get a requirement, open your database tool, and drag out a few tables based on experience. Orders table, users table, products table—you add fields off the top of your head: is_deleted, create_time, update_by... Everything looks reasonable. By the third API endpoint, you realize orders need to support partial refunds and the status field isn't enough. By the fifth endpoint, you discover products have multiple SKU variants, and the previous version of the products table simply can't handle it. So you modify tables, change code, revise APIs, going back and forth.

I once tracked the numbers for a small project: from the first version of the table structure to the final stable version, I went through 5 revisions, with rework time totaling over 10 hours. Even more troublesome was the review—small teams don't have a dedicated DBA, so a "review" meant pulling a backend colleague to look at it for ten minutes, catching only a limited number of issues. After launch, problems like redundant fields, missing indexes, and inconsistent normalization surfaced, and the cost of fixing them was already several times that of the design phase.

The pain points boil down to three: slow design, shallow review, and lots of rework.

What AI Can Do Here

After introducing AI into the database design process, I found it can do at least four things:

1. Generate an initial draft from a business description: You explain the business rules clearly in natural language, and it outputs complete CREATE TABLE statements, including field types, comments, and index suggestions.
2. Run a round of "machine review": Have it play a picky DBA, checking for normalization issues, naming consistency, index soundness, and potential performance pitfalls.
3. Generate adversarial test scenarios: Have it simulate extreme business scenarios (high-concurrency ordering, soft-delete recovery, multi-device login) to see whether the table structure holds up.
4. Produce supporting documentation: Data dictionaries and ER relationship docs, generated in one go.

My Actual Workflow

My process now consists of four fixed steps:

Step 1: Write out the business context clearly and feed it to the AI for an initial draft. The key here is to write the business rules in detail, especially the "edge cases."

Step 2: Switch to a different prompt and have the AI review the draft as a DBA. One important point: tell it to only find faults and offer no comfort, otherwise the output will skew toward "overall pretty good, here are a few minor suggestions."

Step 3: Human decision-making. I go through every suggestion the AI makes—accept, reject, or defer. This step can't be skipped—AI sometimes over-engineers, recommending sharding for a small tool with a few hundred daily active users.

Step 4: Have the AI generate the final DDL and documentation, review it manually, then commit to the database.

Here's the review prompt template I use regularly—feel free to copy and adapt it:

你是一位有10年经验的数据库架构师，现在对以下表结构做严格评审。

业务背景：
【在这里描述业务，包括：核心实体、数据量级预估、读写比例、是否有并发写入场景】

请从以下维度逐项检查并输出问题清单：
1. 范式与冗余：是否存在过度冗余或该冗余没冗余的字段
2. 字段设计：类型是否合理、是否缺通用字段（软删、时间戳、乐观锁版本号）
3. 索引设计：基于我给的查询场景，索引是否缺失或冗余
4. 扩展性：未来半年可能的需求变化，哪些会导致大改表
5. 命名与规范：命名是否一致、注释是否完整

要求：
- 只列问题和修改建议，不要夸奖
- 每个问题标注严重程度（高/中/低）
- 高严重度问题必须给出具体ALTER语句

表结构DDL如下：
【粘贴你的建表语句】

Before and After AI: The Numbers Speak

Using a recent community group-buying mini-program project as a comparison (an independent project, not client data):

Per project, the design phase went from about 10 hours down to around 2.5 hours—roughly one quarter of the original time. Even more important is the reduction in rework—a good chunk of those 4-5 rounds of rework actually went into adapting code, a hidden cost that's hard to measure precisely, but the savings feel even bigger in practice.

On cost, completing the entire workflow via API calls to a large model consumes a negligible amount in token fees for one project's table structure design. Check the official pricing page for exact prices—for indie developers, it's essentially negligible.

A Few Practical Tips

After using this for a while, three lessons are worth sharing:

Don't let the AI do it in one shot. Directly saying "design an order system for me" usually yields a textbook-style generic structure with fields that look complete but don't match your business. The more specific your business rules (e.g., "supports partial refunds" or "the same phone number can have multiple recipient roles"), the higher the quality of the initial draft.

Run the review at least twice. After the first review, have the AI output a revised version, then review again. The second round often still uncovers issues at the indexing and foreign key constraint level.

Humans must retain final decision-making power. The AI doesn't know your actual data volume or your team's maintenance capacity. Its suggestion to "add partitioning to every table" is a liability for a small tool. Treat it as a tireless junior DBA who works overtime for free—not as the architect themselves.

Final Thoughts

Database table structures are the foundation of a project, and the last place you want rework. AI can't understand your business for you, but it can pull you out of the twin traps of "dragging fields by gut feeling" and "having no one to review your design," compressing hours of work into a lunch break. If you don't yet have a go-to AI API to run this workflow, you can register one and give it a try: https://api.thistoken.ai/register

---

Ready to try it yourself? Sign up at https://api.thistoken.ai/register to get your API key and start building.