应用与生态系统：设计数据库之前先决定

应用与生态系统，是在设计任何一张数据库表之前必须回答的一个问题：你在构建的是应用，还是生态系统？应用服务于一种用户做一件事。生态系统服务于多种用户，他们的数据相互连接并在其间流动。这个答案会改变你数据库的一切——生态系统的设计大约复杂10倍——而在地基浇筑之前知道，远胜于之后才知道。

这是我在为自己的平台写任何代码之前回答的问题，也是数据库最终变成现在这个规模的原因。下面讲如何正确地提出这个问题、每个答案会让你承担什么，以及二十分钟就能浮现真相的练习。

决定你整个数据库的那个问题

数据库是地基，而地基的形状取决于将要建在上面的东西。花园小棚和公寓大楼都需要混凝土——但没有人先浇筑一个小棚的地基，然后再决定加盖十二层。软件也是一样：你的数据模型的形状，由你正在构建之物最有野心的那个版本决定，而它是你产品中日后真正难以更改的那一部分。（还不清楚数据模型是什么？先读写给非技术创始人的数据库入门。）

所以设计的第一步不是画表。而是决定你究竟在构建什么。不是功能——而是愿景。

“只是一个应用”是什么样子

应用只有一种用户做一件事。时间追踪器。发票生成器。习惯养成器。它的数据库小得令人耳目一新：一张用户表、一张项目表、一张任务表——完事。简单。

这没有什么不对。如果你的愿景真的是为一类受众打造的专注工具，一个小而干净的数据库就是优势：构建更快、更容易理解、维护更便宜。错误不在于构建应用。错误在于在生态系统的野心之下，打了一个应用的地基。

生态系统是什么样子

我开始做我的平台时，并没有坐下来构建“一个应用”。我坐下来是要构建一个生态系统。愿景是：一个平台，创业公司在上面运营整个业务，加速器管理他们的项目和投资组合，风投追踪项目来源和投资，推广者进行推广并赚取收益——所有人相互连接，彼此对话。

这一段话改变了整个数据库。我需要的不是一张用户表，而是本质上不同类型的组织——创业公司、加速器、风投、推广者——用户以不同角色附属于它们。我需要的不是一个产品的表，而是十个产品——OS、HUB、CAP、Money、People、Score、Pitch、Accelerator、Affiliates、VC——共享在它们之间流动的数据：创始人经营的那家创业公司，就是加速器辅导、风投评估的同一家创业公司。各方之间到处都是关系。

这就是平台运行在964张表上的原因。不是因为我想要复杂——而是因为愿景要求如此。生态系统的数据库不是一个更大的应用数据库；它是另一种对象，就像城市的道路网并不是一条更长的车道。

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

应用与生态系统：实际差异

注意最后一行的不对称。当你只需要应用却选了“生态系统”，代价是浪费一些结构。当你的愿景是生态系统却选了“应用”，代价是地基本身——把用户类型之间的连接改造到从未被设计为相互关联的表上，这类手术会让产品停滞数月。

为什么必须现在决定，而不是以后

因为10倍的复杂度，在你事先知道时完全可控，而在中途才发现时则残酷无比。现在知道，胜过在构建了错误的地基之后才意识到。

尽早决定“生态系统”，还会解锁使生态系统成为可能的那个最重要的结构性选择：从第一天起就为多个组织而设计，每一行数据都恰好属于其中一个。这个模式——多租户——在一开始几乎是免费内建的，之后却几乎不可能硬加上去。它是“应用还是生态系统”这个答案的第一个具体后果，这正是这个问题要排在建表之前的原因。

需要说明的是，这是双向的：如果诚实的答案是“应用”，就构建应用。不要因为生态系统的管道显得更有野心，就给一个专注的工具镀金。罪过不在于小；而在于不匹配。

练习：写下愿景，而不是功能

在你的下一张表之前，花二十分钟写下愿景。不是功能清单——是愿景。三个问题就够了：

所有的用户是谁？不只是显而易见的那一种。还有谁会接触到这个——管理员、合作伙伴、评审、买家、推广者？他们如何连接？他们当中谁需要查看、共享或操作同一批记录？他们共享什么数据？哪些信息是在他们之间流动，而不是存在于某个人的孤岛里？

如果答案是“一种用户类型，没有连接，没有共享”，恭喜：你在构建的是应用，你的数据库可以保持小巧美好。如果答案涉及多种用户交换数据——你在构建的是生态系统，从这一刻起你设计的每一张表都应该知道这一点。

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

常见问题

生态系统比应用更好吗？

不——匹配的比不匹配的好。一个专注的、数据库小而契合其愿景的应用，永远胜过一个半成品的生态系统。重点不是目标更大；而是让你的数据库如实反映你究竟在构建什么。

我可以先从应用开始，再成长为生态系统吗？

可以——前提是地基允许。行得通的折中办法是：把功能的范围定得像应用一样，但对少数几个基础性选择（多租户、把组织作为一等记录、正确的引用关系），要当作生态系统的愿景可能成真来做。功能日后容易加；地基则不然。

生态系统需要多少张表？

没有神奇的数字——964是一个真实的、包含十个产品的生态系统所需要的，而不是目标。诚实的答案是：愿景需要多少就是多少，这正是你要先写下愿景、让表的数量由它自然得出，而不是反过来的原因。

AI会问我“应用还是生态系统”这个问题吗？

不会——这正是危险所在。让AI“给我构建一个平台”，它会乐呵呵地产出一个应用形态的数据库结构，因为应用是它所见过的一切的统计平均值。愿景存在于你的脑子里。明确地陈述它——所有的用户类型、连接、共享的数据——AI才能据此设计。如果不说，你得到的就是公寓大楼下面的一块小棚地基。