我正在为我的公司编写最简单的分析系统。每十个项目我应该收集大约100种不同的事件类型。我们对跨项目分析请求不感兴趣，但事件在所有项目中都有类似的类型。我使用PostgreSQL作为该系统的主存储器。现在我应该决定哪种架构更合适。
第一个架构是每个项目的一个非常大的表（就行数而言），其中包含所有类型事件的数据。它将是大约20或更多列，其中许多可以为空。可能会使用分区按事件类型拆分此表，但表仍然很宽。
第二个架构是很多表（在行数方面相当大但不是那么宽），每个事件类型有一个表。
我将使用不同的连接查询从这些表中检索分析数据（在第一个体系结构的情况下为自联接）。哪一个更可取，哪些是陷阱？
UPD 即可。所有事件都有大约10个共同属性。并且保持属性因事件类型而异。
答案 0 :(得分：1)
过去，我有过类似的情况。有了postgres，你有很多选择。 根据数据输入系统的方式（一次一个/一次）和每个项目的数据量（数百个数据点与数百万个数据点）和查询模式（IE，查询后）数据全在，每晚查询或报告始终在不断运行），有很多选择。另一个因素是如果新的项目类型（有新的数据点类型）可能会出现。
首先，在你的第一架构＆＃34;我想到的第一个问题是：所有＆＃34;数据点都是＆＃34;相同的数据类型（或至少非常相似）。有些文字和其他文字是数字吗？是一些数字和其他浮动？如果是这样，您可能会遇到卷起数据的问题，而无需为每种数据类型构建列或表。 如果您的所有数据都是相同的数据类型，那么您提到的第一个体系结构可能非常有用。
你提到的第二种架构是可以的，特别是如果你不能预测很快会有一堆新的项目类型下来，否则，你会不断修改数据库，我更喜欢避免不必要时。
你没有提到的第三个架构是1和2的组合。基本上有1个表来保存10个公共属性，并使用1或2来保存其他属性。这将有一个优势，特别是如果附加数据不是经常使用的，或者是非数字的。
最后，您可以使用PostgreSQL之一＆＃34;文档存储＆＃34;类型数据类型。您可以将此信息存储在数组，hstores或json中。现在，如果您正在执行大量的聚合函数，这将是相当低效的，因为您可能会计算Pgsql之外的聚合，或者至少运行低效查询。您可以将10个公共字段存储在普通字段中，将其他字段存储为hstore或json。
我没有问你，但很高兴知道如果一个项目中的每个事件都有超过1个数据点（IE是你记录更改，或只是更新数据）。如果你的整体表格的行数少于100,000行，它可能最适合专注于更容易维护和编程而不是性能，因为少量数据非常快，无论它们如何＆＃39 ;重新存储。