在数据库中使用大列是否有缺点？

Question

我的数据库存储各种问题的用户统计信息。没有问题类型表，因此我没有在问题类型上使用连接表，而是为用户在用户表中的序列化哈希映射中为每种类型的问题存储了用户统计信息。显然，这导致了一些体积适中的用户行 - 我自己用户的序列化统计数据大约为950个字符，我可以想象它们很容易在高级用户上增长到5 kb。

我从来没有读过任何书中这么大的专栏的例子。在我的表中使用这么大/可变的列会严重影响性能吗？我应该在表格中添加问题类型，并将用户统计信息作为单独的表吗？

我目前正在使用PostgreSQL，如果这是相关的。

Answer 1

我在ProcessMaker等系统上看到了这种序列化方法，这是一个Web工作流和BPM应用程序，并以序列化方式存储其数据。它的表现相当不错，但根据这些数据构建报告真的很棘手。

您可以（并且应该）规范化您的数据库，如果您的信息模型不经常更改，这是可以的。

否则，您可能想尝试非关系型数据库，如RavenDB，MongoDB等。

Answer 2

最大的缺点与select *的情况有关。如果你有一个特定的字段列表，你不太可能有一个大的问题，但是select *有很多TOASTed列，你有很多额外的随机磁盘I / O，除非一切都适合内存。选择较少的列会使事情变得更好。

在像PostgreSQL这样的对象关系数据库中，数据库规范化与纯粹的关系模型相比具有不同的权衡。一般来说它仍然是一件好事（正如我所说的那样，在你的数据库中执行OR之前，它可以轻松地推动关系模型），但是你可能认为它不是绝对必要的。纯粹的关系数据库。此外，您可以添加函数来使用regexp处理该数据，从JSON中提取元素等，并将这些函数拉回到您的关系查询中。因此，对于无法轻松规范化的数据，大的无定形“docdb”字段并不是一个大问题。

Answer 3

取决于您需要的主要查询：

• 如果您需要选择所有（或大多数）列的查询，那么这是最佳设计。
• 但是，如果您主要选择列的子集，则可能值得尝试“垂直分区” ¹ 表，因此您可以避免“不需要的”列的I / O并提高缓存效率。 ²

当然，所有这一切都假设序列化数据从数据库的角度来看就像“黑盒子”一样。如果您需要以某种方式搜索或约束该数据，那么只存储一个虚拟字节数组会违反atomicity的原则，因此违反了1NF的原则，因此您需要考虑规范化您的数据...

---

¹ I.e。将很少使用的列移动到第二个表，该表与原始表的关系为1：1。如果你正在使用BLOB，可以通过声明BLOB的哪个部分应该“保持在线”来实现类似的效果 - 超过该限制的任何BLOB的剩余部分将被存储到与表的“核心”分开的一组页面中“页面。

² DBMS通常在页面级别实现缓存，因此行越宽，它们就越少适合磁盘上的单个页面，因此在缓存中的单个页面中的

Answer 4

您无法搜索序列化数组。