0

我关心数据库表的性能，我必须存储与客户调查应用程序相关的数据。

我有一个数据库表，用于存储来自调查的客户回复。由于调查问题会根据客户 i 而变化，而不是使用每个 questionid 作为列来定义表模式，因此将其定义如下

    customerdata(customerid  varchar, 
         partkey varchar, 
         questionkey varchar, 
         value, varchar,
         version, int,
         lastupdate, timestamp)

在哪里：

partkey: 是零件的简码 (part1,part2...)

questionkey：是问题的简码，例如年龄、性别等

由于一些客户填写了两次调查，三次等我添加了版本列。

在这种设计中，customerid、partkey、questionkey 和 version 是主键。

我担心这种设计的性能。我应该将其他主键定义为索引吗？那会有帮助吗？到目前为止，对于 30 个客户，我有 7000 条记录。我预计最多有300-500。你怎么看 ？

4

2 回答 2

1

听起来像一个非常小的数据库。我怀疑您会遇到性能问题，但如果您在查询时检测到任何问题partkey，questionkey或者version稍后您可以随时添加一个或多个索引来解决问题。没有必要解决您没有并且可能永远不会遇到的性能问题。

只有当您必须执行不将该customerid字段用作主要过滤器的时间敏感查询时，才会出现性能问题。我怀疑你会有一些这样的查询（当你想跨客户聚合数据时），但我怀疑它们的时间敏感度足以受到我期望从这样的一秒或更短的响应时间的影响小数据集合。如果是，则添加索引。

另外，请注意一个表只有一个主键。该键可以使用多个列，因此您可以说列customerid、partkey、questionkey和version是PRIMARY KEY 的一部分，但您不能说它们都是“主键”。

于 2012-10-09T21:55:28.173 回答
-1

rownumber-wise，我体验过超过 100.000 行的 mysql 数据库，它运行得很好，所以你应该没问题。

尽管如果您运行复杂的查询则情况不同，这更多地取决于数据库设计而不是行号。

于 2012-10-09T21:42:59.567 回答