数据库优先案例研究：先建表，再做第一个界面

在这个数据库优先案例研究中，我在做出任何一个界面之前就设计好了数据库——18个月后，已有1,000张表且仍在开发，它从未需要重建。一次都没有。这就是案例：那些不起眼的最初几周花了什么，又究竟换来了什么。

方法本身——为什么你的数据必须先于你的界面——有专门的一篇：数据库优先开发。这一篇是证明。一种方法很容易让人点头称是，也很容易在你迫不及待想在屏幕上看到东西的那一刻被抛弃。所以，这里讲的是我把整个产品押在“先做枯燥的部分”上之后，实际发生了什么：FIKR Space，如今是11款集成产品、超过300万行代码，全部建立在一个在这一切存在之前就设计好的数据基础之上。

数据库优先案例研究：两周半，没有任何东西可展示

第一阶段——花一周梳理领域。在写下任何一行代码之前，我列出了系统将会触及的所有领域。总共超过20个领域，分为五组：

• 核心：组织、用户、团队、权限
• 产品：项目、任务、目标、冲刺
• 资金：股权结构表、融资轮次、交易、估值
• 平台：加速器项目、申请、批次、课程
• 支持：评论、附件、通知、活动日志

第二阶段——花一周设计每一张表。每张表都有相同的骨架：这条记录归哪个组织所有、谁在何时创建、谁在何时最后修改，以及用“隐藏记录”而非“销毁记录”的方式来处理删除。在这个骨架之上，每个领域再加上自己特有的字段，以及以可编辑数据形式存储的状态与类型列表——绝不写死在代码里。

第三阶段——花三天梳理关系。绘制一张完整的连接图：哪些记录属于哪些记录，哪些是多对多关联，哪些——比如评论和附件——可以附加到任何对象上。

总计：大约两周半。整个基础，设计完毕并连接起来——此时还没有任何一个界面。在旁人看来，我什么也没造出来。人们觉得我疯了：“为什么不直接开始做，边做边想？”因为我没有时间重来，没有钱可浪费，也没有容错的余地。数据库必须一次做对。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

数据库优先的地基究竟换来了什么

然后回报开始了——而且从未停止。下面是FIKR Space经历的每一次大改版，以及每一次对数据库的要求：

五次界面大改。零次数据库改动。界面只是通向数据的窗户——我可以无休止地重新裁剪窗户，因为墙从未移动。这种不对称就是数据库优先的全部理由：你可以彻底重新设计界面；你无法彻底重新设计数据库。

这个地基还换来了另外两样钱买不到、事后也补不上的东西。第一，唯一的事实来源：仪表盘和任务列表永远不会互相矛盾，因为每个界面都向同样的表问同样的问题。第二，从第一天起就做到客户隔离：每条记录都标明归哪个组织所有，所以一位客户的数据不可能泄漏到另一位的账户里——而我此后添加的每个功能，都自动继承了这种保护。

我怎么可能事先知道需要1,000张表？

我不知道。我并不是提前知道每一张表——有些领域在演进，字段也是一路增加的。但我了解这个系统：一个面向初创公司、投资人和加速器的多租户平台，处理真金白银，需要复杂的权限和审计追踪，多个产品共用同一个地基。了解系统，就能知道必须存在哪几类表——实体、关系、查找表、审计日志——哪怕你还不知道每个字段。当新需求出现时，它们契合现有的模式，而不是与之对抗。

这就是架构师那一半的工作——完整的分工见你是架构师，AI是建造者。AI完全按照我的指定生成了每一次迁移。它没有做任何架构决策。纯粹是执行。而且它不断地与这套纪律作对：忘记组织标记、跳过索引、提出捷径——这些警示信号都整理在AI自信地犯错的11个迹象里。

反面假设：跳过它要付出什么代价

界面优先的版本，故事是这样的。第一周，你做了一个漂亮的仪表盘，并建了一张表来喂它。第二周，你做了一个任务列表，又建了一张表。第三周，仪表盘显示15个任务，而任务列表显示18个——因为你现在有了两个事实来源，没人知道它们是何时分叉的，也不知道哪个才对。

现在把它放大。假设我跳过了客户隔离，之后才需要补上：每张表都要改，每个查询都要重写，每条访问规则都要创建，所有现有数据都要迁移。要花数周的高风险工作，同时触及所有东西——这正是会让独立产品送命的那种大手术。因为它从第一天起就设计在内，所以根本不存在需要事后补救的东西。

钱呢？建造这一切的全部工具开销是3,250欧元——明细见3,250欧元的技术栈。昂贵的投入从来不是现金，而是在没有任何东西可演示的情况下，把两周半花在地基上的那份自律。数百个功能之后，每一个都严丝合缝，这仍然是我在产品上做过的回报最高的投资。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

常见问题

为什么要在做任何界面之前设计整个数据库？

因为界面可以改，数据库不能——至少改起来不便宜。界面只是通向数据的窗户，想多频繁地重新设计都行。但在一个已上线的产品下面重构数据，意味着同时触动每一个功能。把地基做对，建在上面的一切就会屹立不倒。

设计数据库花了多长时间？

大约两周半：一周梳理20多个领域，一周用共同的骨架设计每一张表，三天梳理它们之间的关系。这就是地基的全部价格——对比的是18个月、零次重建的构建过程。

数据库曾经需要重建吗？

没有。18个月里一次都没有。字段增加过，一些领域也有演进，但始终是在现有模式之内。五次完整的界面改版——仪表盘、导航、布局、样式、移动端——彼此之间没有产生任何数据库改动。

我的产品需要1,000张表吗？

不需要。这个数字反映的是11款集成产品共用同一个地基。这条原则可以缩小到任何规模：列出系统里的每个实体，梳理它们如何关联，在做界面之前把一切设计好。无论你的产品需要十几张表还是数百张表，这套纪律都是一样的。