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

在帮助构建几个初创公司的分析栈之后，开始看到一些模式。有时这些模式是令人高兴的：几乎每个人都喜欢从对发生的事情一无所知，到对上周发生的事情有一个模糊的了解的时刻。其他模式则不那么令人兴奋，通常涉及到关于数据模型或模式的决定。

以下将要讨论的反模式专属于初创企业。其中一些模式对于后期发展阶段的公司来说实际上是好主意，但对于资源有限、处于产品市场匹配前的初创企业来说，这些是您不需要犯的错误。

无需多言，以下是早期数据分析中五大痛点来源：

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

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

通过在数据库中污染测试数据，您已经对公司的所有分析（以及内部工具构建）征收了税费。您可以平衡这笔税费与交易效率或开发者生产力。有时这笔税费是值得的，有时则不然。对于大公司来说，交易效率是一个足够重要的目标，您可以花费几位工程师或分析师的时间来清理结果。

如果您规模较小，可能承担不起这笔费用，您可能需要在其他方面做出权衡。

关于用户行为、满意度和价值的重要问题中，很大一部分围绕会话指标展开。无论是称为“会话”、“对话”、“支持联系”还是其他名称，这些指标都指与用户相关的多个离散事件，应将它们分组并作为一个单一概念处理。然而，初创企业的数据模型往往未能以商业词汇捕捉这个基本概念。

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

在大量负载下删除数据库中的行是件坏事。软删除是一种常见的架构工具，可以减轻删除和随后的压缩（或清理）的性能影响。此外，软删除使恢复删除数据变得容易。

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

半结构化数据（例如，字段编码为JSON）在存在多种不同结构的情况下很有用。随着数据库的增大，半结构化数据还可以帮助避免在重读或写负载下迁移大型表的问题。

然而，在尝试从数据库中提取数据时，半结构化数据也可能导致很多麻烦。通常，半结构化数据具有仅通过惯例强制执行的架构，这些架构可能会不可预测地变化，或者由于短暂的错误而出现偏差，总的来说，需要大量的事后清洁才能变得有用。

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

公司技术堆栈中存在大量不同的数据库通常表明以下三种场景之一：

随着添加的数据库数量增加，你需要承担大量的运营开销。此外，每个额外的数据库都是另一组你需要放入分析数据库的数据。这些数据库将具有略微不同的语义、数据类型和自然数据模型，你需要整理这些。

因此，抵制让小型功能更容易实现的诱惑，因为这会使运营和分析变得更加困难。

在思考你的数据模型是否考虑到你的分析和交易需求时，识别以下内容是有用的

你正在寻找一个数据模型，该模型可以最小化所有这些不同查询的痛苦。一般来说，业务指标的查询是最重要的，所以如果引入一点复杂性来简化应用程序的更新和读取，将有助于查询业务指标，那就这么做。这将最大化整体生产力，因为通常在应用程序端的工作查询比常见分析或业务智能问题要少得多。

此外，应用程序的查询通常在源控制中进行，封装在自动化测试中，并且通常更加硬化。业务指标的查询通常分散，由许多人编写，通常控制较少。所以尽你所能让企业容易获取其需要做出更好决策的指标。

在建立分析时，你将会犯错误。这里是如何犯更少的错误。