初创公司犯的常见数据模型错误

数据建模很难。以下是你在开发模型时应避免的一些失误。

在帮助一些初创公司搭建了数据分析栈之后，你会看到一些模式。有时这些模式是令人欣喜的：几乎每个人都喜欢从一无所知到对上周发生的事情有模糊概念的时刻。其他的模式则不那么令人称道，通常涉及到围绕数据模型或模式的决策。

需要注意的是，我们下面将讨论的反模式是初创公司特有的。其中一些模式实际上是后期公司的良好主意，但对于小型、未达到产品市场契合度、资源有限的初创公司来说，这些是你不必犯的错误。

废话不多说，以下是早期分析的五大痛点来源：

1. 用测试或假数据污染你的数据库

无论是测试账户、员工账户、不同的数据程序，还是通过猫咪心灵感应收到的订单，太多的公司包含了需要你在很多或大部分查询中忽略某些事件或交易的数据。

通过用测试数据污染数据库，你为公司所有的数据分析（和内部工具构建）引入了税费。你可以将此税费与交易效率或开发人员的生产力进行权衡。有时这个税费是值得的，有时则不然。对于大公司来说，交易效率是一个足够重要的目标，你可以花几位工程师或分析师的时间来清理结果。

如果你规模很小，很可能你负担不起，你应该在其他地方做出权衡。

2. 事后重构会话

关于用户行为、满意度和价值的大量重要问题都围绕着会话指标。无论它们被称为“会话”、“对话”、“支持联系”还是其他名称，这些指标都指代与用户相关的多个离散事件，应将它们分组并视为一个单一概念。然而，初创公司的数据模型未能捕捉到业务词汇中的这一基本概念，这种情况却令人担忧地普遍。

会话通常是事后重构（即，在事后）的，这通常会导致很多脆弱性和痛苦。构成会话的确切定义通常随着应用程序本身的变化而变化。此外，用户会话在客户端或处理客户端请求的服务器上通常有很多上下文。在你的应用程序中分配一个会话、支持票据或对话 ID，比事后尝试重构会话要容易得多。

3. 软删除

大规模删除数据库中的行在负载很大的情况下是一件坏事。软删除是一种常见的模式工具，可以减轻删除带来的性能影响以及后续的压缩（或清理）。此外，软删除可以轻松地“取消删除”行以恢复已删除的数据。

另一方面，软删除要求每一个读取查询都要排除已删除的记录。如果你只考虑应用程序的数据调用，这可能看起来不算太糟。然而，当乘以你运行的所有数据分析查询时，这种排除很快就会成为一个严重的拖累。而且，软删除引入了另一个不同用户可以做出不同假设的地方，这可能导致需要调试的不一致的数字。

4. 误用半结构化数据

在随时间推移存在多种不同结构的情况下，半结构化数据（例如，编码为 JSON 的字段）可能很有用。随着数据库的增大，半结构化数据还可以避免在大量读写负载下迁移大型表的麻烦。

然而，半结构化数据在从数据库中提取数据时也可能带来很多麻烦。通常，半结构化数据具有仅由约定强制执行的模式，这些模式可能不可预测地更改，或因暂时性错误而偏离，并且通常需要大量的事后清理才能有用。

有时，半结构化数据字段是推迟思考所需结构直到*在*编写完一个功能*之后*的借口。在这种情况下，你实际上拥有结构化数据，只是未强制执行，容易出错，并且通常使用起来很麻烦。一个简单的测试：如果 JSON 字段的每个实例都有相同的四个字段，你可能应该分解该结构。

5. “适合工作的数据库”综合征

公司技术栈中存在多种不同的数据库通常表明以下三种情况之一：

• 一个非常庞大、复杂的公司，拥有广泛的需求和部门。
• 一个高度专业化、表现顶尖的工程和运维团队，致力于解决非常困难的问题，需要全面优化应用程序的各个方面。
• （最常见的是）一个小型团队，在他们浅尝辄止理解的技术中不断地处理各种紧急问题。

每增加一个数据库，你就会承担大量的运维开销。此外，每个额外的数据库都需要你将其数据整合到数据分析数据库中。这些数据库将具有略微不同的语义、数据类型和自然数据模型，你必须理清。

因此，抵制让一个小功能更容易实现的冲动，因为这会使整体的运维和数据分析变得更加困难。

一个技巧：让业务指标易于获取

在考虑你的数据模型是否能满足你的分析和交易需求时，识别以下几点很有用：

• 业务关心的 10 个重要指标
• 应用程序最常运行的 10 个更新查询
• 应用程序最常见的 10 个读取模式

你正在寻找一个能最大程度减少所有这些不同查询痛点的数据模型。总的来说，业务指标的查询是最重要的，所以如果引入一些应用程序更新和读取的复杂性可以使业务指标的查询更容易，那就去做。你将最大限度地提高整体生产力，因为工作量最大的查询通常在应用程序方面比常见的分析或商业智能问题少得多。

另外，应用程序的查询通常在源代码控制中完成，封装在自动化测试中，并且通常更加健壮。业务指标的查询通常分散在各处，由多人编写，并且通常控制程度较低。所以，尽你所能，让你的业务部门能够轻松获取其所需的指标，以做出更好的决策。