4

我正在计划一个数据库结构，它将存储相当多的数据。我们需要为每个项目存储 50 个不同的数据“列”。添加一个时间戳，这给了我们 52 列（和 2 个索引，这将是过滤这些数据的唯一方法）。这个数据库每天都会添加几千行（并且永远不会更新），并且会使用一段时间。

所以我的第一选择是将所有东西都塞进一张桌子。让我在想 52 列是否有点糟糕或什么？我从来没有考虑太多。当然插入代码会很烦人，但它不像我要手动编写它们。

我应该将它拆分为多个表（然后使用联接或其他什么？），还是有这么大的表没有问题？如果它有所作为，我正在使用 mysql。

添加：澄清我将如何使用数据：

  • 排序和过滤只会在索引列上进行。
  • 在目前的计划中，这些数据将用于“人类消费”，因此我们将始终访问整行（在需要时将其输出到 csv 或其他任何内容）。
  • 不会有删除或更新。会有很多插入和（不太频繁）选择。
  • 与数据库中的其他数据不会有任何形式的“链接”（外键或其他）
  • 所有的数据都与同一件事有关。没有“明显”的方法可以对其进行规范化，将其分解为表格只会将分类类别放入数据中并像这样存储它们。
4

4 回答 4

4

使设计不幸的并不是列的数量。这是所有这些列是否真的属于同一个表。当数据与表的键不紧密相关时，数据规范化规则对将数据存储在一个表中的后果有很多说明。

您应该了解规范化规则以及不遵循它们时会发生什么 稍后，您可能还应该了解故意偏离规范化规则可能会导致良好设计的情况。但是，在您了解规范化表格设计的价值之前，您无法了解这一点。

于 2012-07-23T11:39:38.113 回答
2

如果可能的话，我认为你应该把它分成几个表（规范化表）。然后，我的建议是，您应该对经常访问的表使用索引。索引可以使查询变得更快。但缺点是，插入新数据的过程会变慢。

于 2012-07-23T10:02:25.307 回答
1

一个表中有 52 列本身并没有什么问题。

但是，如果您经常只查询这些列的某个子集，您可能会发现将这些经常使用的列一起存储在它们自己的表中而不存在多余的列会带来一些性能优势。

也就是说，在需要时与辅助表连接以访问额外的列会降低性能（INSERT两个表之间的操作也会变慢），因此需要进行权衡；另请注意，多个表会导致数据重复（至少是外键），因此总体上会消耗更多空间。

您可以对这两种方法进行基准测试，看看在您自己的情况下会出现什么差异。就个人而言，我会选择一张桌子，直到性能决定我在别处寻找。

于 2012-07-23T10:09:57.427 回答
0

拥有巨大的表会使非索引列的查找和排序更加麻烦和昂贵。

最好有小而高效的桌子。

您可以选择将数据拆分为多个一对一的表，或者考虑使用键/值表。

如果您有兴趣，请参阅键值表信息：http: //www.devshed.com/c/a/MySQL/Database-Design-Using-KeyValue-Tables/

于 2012-07-23T10:06:22.720 回答