一个动态表单构建器的数据库架构

Question

我知道已经有一个类似的问题的答案，但我认为答案不够强大，所以我会提出我的具体问题。

• 假设： 动态表单构建器，用户可以创建结构未知的表单。

• 解决方案： 表单提交后，数据将被存储在两个表格中：

  1. FormSubmissionHeader表格将存储一些关于提交的基本数据（formid、userid、datetime等）
  2. FormSubmissionFieldsData表格(FormSubmissionHeaderID，FIELDID，FIELDVALUE)

我对这个解决方案的问题是针对大规模使用：
假设我有100万个用户，
每个用户将拥有3个表单
每个表单将有10个字段
每个表单每天将有5个提交。

因此，FormSubmissionHeader每天将增长到1百万X3X5=1500万行。

而FormSubmissionFieldsData将增加15X10（每日提交数，字段数翻倍），也就是每天1500万行。

因此，基于这个解决方案：

我不认为它能够工作。

我看到两种替代方案：

1. 使用MONGODB存储提交的标题和数据（非关系型数据库）

2. 动态创建表格以存储每个表单的数据，并直接在其中使用相关的数据类型。

这是我看到的一个类似的问题。

Wufoo的数据库架构-你会如何设计？

我想知道你们对此有什么看法，或者能否提出其他建议？

- dontknow

---

可能是Wufoo的数据库架构-你会如何设计它？的重复问题。 - Barif

是的，因为我不明白它怎么能够运行。 - dontknow

Answer 1

你必须努力说服我，认为每天处理1.5亿行数据在今天这个时代是很多的。这取决于你计划如何处理提交的数据。只要正确索引，大多数查询都可以正常工作。

但是如果你真的需要减少行数，你可以将表单提交保存为json格式。我相信PostgreSQL原生支持此功能。你可以同时获得结构化和半结构化数据的最佳效果。

因此，表格本身不会改变，但提交的表会有一些关于提交的列（用户、表单ID、日期等），以及一个json列，其中包含答案作为json对象，你也可以对其进行查询。

- OmerGertel

---

当您的表格很大时，恢复时间可能会更长，这就是为什么我试图防止表格过大的原因。关于“您可以将表单提交保存为JSON格式”，感谢Omer。实际上，目前这就是我正在做的事情，但我仍在思考是否有什么遗漏。PG还好，但在这种情况下，为什么不使用Mongo呢？它应该能够更好地进行水平扩展。 - dontknow

我假设您已经有一些SQL数据库，并且宁愿继续使用它（这实际上取决于偏好和现有代码。例如，在Django中，保留ORM是一个非常好的想法，并将表单提交与现有模型联系起来是一个重要的优点）。此外，如果您需要进行聚合操作，我认为在pg上更容易实现。 - OmerGertel

谢谢Omer的回复，我会再等一段时间看看是否有其他不同的意见。 - dontknow