我正在尝试设计一个数据库来存储来自不同网站的用户信息。基本上是用户信息的聚合，这样用户就不必登录不同的网站并在一个地方获得类似的信息。有点像 mint.com 问题是这些不同的网站中的大多数都包含不同的数据子集。例如，一个站点需要大约 47 列，而另一个站点只需要大约 13 列。现在在我看来，合乎逻辑的事情是将每个站点分解成它自己的表。然而，一张有 47 列的表看起来很麻烦，我试图将它分解成更小的表只会让它看起来更疯狂。我的一个朋友建议，如果网站上的字段之间存在相似之处，我可以只有三个表。像这样：
上面的示例基本上采用任何可能是列名的内容，如果我将它设为每个网站架构的表，并将该列名作为条目放入“field_name”列中。由于每个站点上用户信息的更改每天仅发生一次（在清晨），因此复合键将在当天保持唯一。而不是一个网站的所有值都在一行中，每个值都在自己的表中，它们基本上都是分段的，现在获取数据涉及稍微长一点的查询，所有的事情基本上都在 WHERE 子句中完成。
如果说我可以使用来自一个网站的所有 13 个并将其与来自具有 47 列的网站的 13 个结合起来，并且只需要担心 34 个列并使用映射表将数据映射到正确的站点，那将非常好。然而，我已经分析了数据，但没有办法做到这一点。每个站点都必须使用所有字段，因为它们不够相似，无法组合。这意味着上面示例中的数据表每天将生成大约 120 行。我真的很喜欢这个概念......如果我的任何要求发生变化，我就不必在我的代码中编辑架构，将另一个值添加到 field_name。这似乎是与其他方式相比的唯一主要优势。
将每个网站分成自己的表并让 4 个表每天只生成 4 行，尽管一个表有 47 行，还是更有意义做类似上面的示例以获得更多可伸缩性......？