初创公司犯的常见数据模型错误
数据建模很难。在开发模型时，这里有一些需要避免的失误。
在帮助一些初创公司构建分析堆栈后，人们开始看到一些模式。有时这些模式是令人愉快的：几乎每个人都喜欢从一无所知到对上周发生的事情有一个模糊了解的时刻。其他模式则不那么棒，通常涉及围绕数据模型或模式的决策。
值得注意的是，我们将在下面讨论的反模式是针对初创公司的。其中一些模式实际上对于后期公司来说是很好的主意，但对于小型、尚未实现产品市场契合、资源受限的初创公司来说，这些是您不需要犯的错误。
闲话少说，以下是早期分析中的五大痛点来源：
1. 用测试或虚假数据污染您的数据库
无论是测试账户、员工账户、不同的数据程序，还是通过猫科动物心灵感应而来的订单，太多公司都包含需要在许多或大多数查询中忽略某些事件或交易的数据。
通过用测试数据污染您的数据库，您给公司的所有分析（和内部工具构建）带来了额外负担。您可以权衡这种负担与事务效率或开发人员生产力。有时这种负担是值得的，有时则不然。对于大型公司来说，事务效率是一个足够重要的目标，您可以负担得起花费几位工程师或分析师的时间来清理结果。
如果您是小公司，很可能您负担不起，您应该在其他地方进行权衡。
2. 事后重构会话
相当一部分关于用户行为、满意度和价值的重要问题都围绕着会话指标。无论它们被称为“会话”、“对话”、“支持联系”还是其他什么，这些指标都指与用户相关的许多离散事件，这些事件应该被分组并作为一个单一概念来处理。然而，初创公司的数据模型未能捕捉到这个基本的业务概念，这种情况却令人担忧地普遍存在。
会话通常是事后（即在事件发生后）重构的，这通常会导致许多脆弱和痛苦。组成会话的确切定义通常会随着应用程序本身的变化而变化。此外，用户会话在客户端或处理客户端请求的服务器上通常有很多上下文。在您的应用程序中分配会话、支持票证或对话 ID 比事后尝试重构会话要容易得多。
3. 软删除
在大规模部署中，在大量负载下删除数据库中的行是一件坏事。软删除是一种常见的模式工具，可以减轻删除和随后的压缩（或清理）带来的性能损失。此外，软删除可以轻松地“取消删除”行以恢复已删除的数据。
另一方面，软删除要求每个读取查询都排除已删除的记录。如果您只考虑应用程序数据调用，这可能看起来没那么糟糕。然而，当应用于您将运行的所有分析查询时，这种排除很快就会成为一个严重的拖累。此外，软删除引入了另一个不同用户可以做出不同假设的地方，这可能导致您需要调试的不一致数字。
4. 滥用半结构化数据
半结构化数据（例如，编码为 JSON 的字段）在存在多种不同结构的情况下可能很有用。随着数据库变大，半结构化数据还可以帮助避免在大量读取或写入负载下迁移大型表的麻烦。
然而，在尝试从数据库中获取数据时，半结构化数据也可能导致很多麻烦。通常，半结构化数据具有仅通过约定强制执行的模式，这些模式可能会不可预测地更改，或者由于瞬时错误而出现偏差，并且通常需要大量事后清理才能有用。
有时，半结构化数据字段是推迟思考您需要的结构直到您编写功能之后的借口。在这种情况下，您实际上拥有结构化数据，只是它未被强制执行，容易出现错误，并且通常使用起来很痛苦。一个简单的测试：如果 JSON 字段的每个实例都具有相同的四个字段，您可能应该分解该结构。
5. “为工作选择正确的数据库”综合症
公司技术堆栈中存在多种不同数据库通常表明以下三种情况之一：
- 一家真正庞大、复杂的公司，拥有广泛的需求和细分。
- 一个高效、顶级的工程和运维团队，正在处理非常困难的问题，需要高度优化应用程序的所有方面。
- （最常见的情况是）一个小型团队，不断处理他们只粗浅了解的技术中的紧急问题。
每增加一个数据库，您就会增加大量的运营开销。此外，每个额外的数据库都是另一组数据，您需要将其放入分析数据库。这些数据库将具有略有不同的语义、数据类型和自然数据模型，您需要解决这些问题。
因此，抵制让小功能更容易实现的冲动，因为您将使整个操作和分析变得更加困难。
一个建议：让获取业务指标变得容易
在思考您的数据模型是否考虑了您的分析和事务需求时，确定以下内容很有用：
- 业务关心的 10 个重要指标
- 应用程序最常运行的 10 个更新查询
- 应用程序最常见的 10 种读取模式
您正在寻找一个能够最小化所有这些不同查询痛苦的数据模型。一般来说，业务指标的查询是最重要的，因此，如果为应用程序更新和读取引入一点复杂性会使业务指标的查询更容易，那就去做吧。您将最大限度地提高整体生产力，因为应用程序端的工作负载查询通常远少于常见的分析或商业智能问题。
此外，应用程序的查询通常在源代码管理中完成，包含在自动化测试中，并且通常更加健壮。业务指标的查询通常分散、由许多人编写，并且通常更少受到控制。因此，尽您所能让您的企业轻松获取所需的指标，以便做出更好的决策。