mysql - 在数据库列中存储结构化数据？

Question

我一直在与同事争论将结构化数据(例如 XML 或 JSON)存储在数据库列中而不是创建子表是否是个好主意。例如，假设我们需要存储有关问题的信息。两种类型的问题是多项选择和评分(例如评分从 1 到 10)。我通常会创建如下所示的结构:

Table                   |   Columns
------------------------------------------------------
Question                | ID, Title, QuestionTypeId
Question_MultipleChoice | QuestionId, Choice
Question_Rating         | QuestionId, Min, Max
QuestionTypes           | ID, TypeName

我的同事认为最好将信息存储在带有子信息列的单个 Question 表中。例如:

Question
----------------
ID
Title
SubInfo  <-- JSON

因为它可以通过避免 JOINS 使查询更简单并且可能更快。是否有理由应避免这种类型的数据库结构？如果您需要根据 SubInfo 列中的数据进行查询，这似乎是个坏主意，但如果不需要，这是一个合理的数据库结构吗？

Answer 1

就我个人而言，调查是一种情况，我认为不进行任何规范化并按原样存储 JSON 是更好的选择。

没有它，您最终会遇到各种您最终想要管理的奇怪用例。除了整理各种选择题外，您还需要管理其中的“其他”答案、条件问题、条件问题组等等。更重要的是，调查与其他形式的数据一样，会发生变化，当它们发生变化时，事情就会从令人生厌的事情变成令人发指的事情。

JSON 的优点在于，由于调查在概念上相互独立，您几乎不需要甚至不需要从一个到另一个的引用完整性，因此您不妨将整个问题和选项树存储为一个JSON blob，并担心在您的应用中对其进行格式化。

对于每个提交的答案都一样，就此而言:获取原始 blob，将相关答案标记为选中等，然后按原样存储生成的 JSON，而不是存储引用到原始问题以及已回答的内容。这将使您能够轻松跟踪用户实际回答的内容，而不是当前版本的调查所说的任何内容，并且无论调查自最初回答以来有多大差异，都可以这样做。

如果您以后需要挖掘答案，请注意 Postgres 允许在整个字段上使用 GIST 索引对 JSON 进行索引，在表达式上使用 BTREE 索引。