我正在开发一个星型模式来分析发布的表单数据。表单数据将发布到的站点实际上是托管表单的站点外部，因此只有表单中的数据可用。我将提供一些选项，包括隐藏字段，原始引荐来源，会话ID等一些额外的有用信息。
我将能够使用正则表达式来匹配某些数据类型并将它们拉出到特定维度，例如邮政编码。
我有一个处理维度的任意性质的解决方案，它不是一个伟大的，但它会起作用。
我遇到的问题是我不知道在我的事实表中会有什么，它不像我可以汇总的一个很好的数值。除了“是的，有一个表格帖子”满足这些标准的事实。
我想知道我是否以正确的方式接近这个？我使用错误的工具来完成工作吗？或者我错过了什么？
西蒙。
更多细节：
有两个功能区域，根据标准过滤表单帖子，例如两个时间戳之间。但是在过滤方面几乎任何东西都可以争夺。然后，选定的表单帖子将用于生成用于导出的csv文件。
另一个主要领域是分析，研究广告支出转化为客户线索是一个明显的起点。也有点开放，取决于表单数据。
答案 0 :(得分：2)
您没有设计星型模式。您正在设计一个Entity-Attribute-Value表，其中包含您要识别的所有问题。
如果你真的不知道你的数据是什么样的，即存在哪些表单字段以及每个字段应该使用哪种数据类型，那么关系数据库就不是保存信息的正确工具。尝试使用XML或YAML或JSON。这些是结构化但动态的格式。您可以动态建立元数据。您可以将整个表单实例存储在数据库的文件或BLOB中。
答案 1 :(得分：0)
没有测量的事实表是可以的 - 它们只是被称为“无事实的事实表”。但是你仍然通常在其中放置一个row_count列 - 即使它总是有一个值 - 来轻松添加汇总表。并且您最终可能会在以后添加其他测量值 - 例如测量术语的情绪。
我不会太担心这看起来不像仓库101的例子 - 有很多极端情况会发生奇怪的事情。你当然可以拥有field_name＆amp; field_value as columns，如果没有field_name，甚至只是field_value。这样可行。它提供了很大的灵活性。
但是你错过了一些重要的功能。由于给定的项目或对象实际上是跨多行分割的 - 典型的sql过滤效果不佳。您通常需要将所有行拉入一个可以将它们作为一个整体进行评估的小应用程序 - 或者编写一些非常复杂的多步骤sql，其中将每行评估的布尔结果插入临时表，然后按session_id分组（或无论等价物，然后最终评估和/或逻辑。
另一个选择 - 是走这条路，但逐渐开发你的ETL解析功能，以便随着时间的推移你可以把这些东西拉到更传统的维度。也许这会成为您的临时表或原始表，但您尝试让大多数报告都达到更传统的星型模式。
最后一个选项 - 考虑非关系数据库。更面向文档的东西可以为您提供更好的功能。