0

我必须决定如何计划用于存储日期的表。

我为每个用户设置了大约 20 个不同的日期，并且猜测现在有 100 000 个用户并且还在增长。

所以问题是对于 SELECT 查询，如果我制作有 20 个字段的表，什么会更快？例如

“用户日期”

userId, date_registered, date_paid, date_started_working, ... date_reported, date_fired 20 个字段，表中有 100 000 条记录

或制作 2 个表，就像第一个表“date_types”一样，其中包含 3 个字段和 20 条记录用于上述列名。

   id, date_type_id, date_type_name

    1       5        date_reported
    2       3        date_registerd
    ...

第二个表有 3 个字段的实际记录

“用户日期”

userId, date_type, date
   201       2      2012-01-28
   202       5      2012-06-14
 ...

但随后有 2 000 000 条记录？

如果我需要添加更多日期，我认为第二个选项更通用.

那么你认为哪个选项会更快？

4

5 回答 5

1

较长的表将具有较大的索引。更宽的表会有更小的索引，但会占用更多的心理空间，并且可能会有更多的开销。您应该仔细检查您的模式以查看规范化是否完成。

但是，我会选择您的第二个选项。这是因为如果字段为空，您不一定需要存在这些字段。因此，如果用户没有被解雇，则无需为他们创建记录。

于 2013-02-20T01:14:50.917 回答
1

确定这一点的最佳方法是通过测试。一般来说，您所说的数据大小（20 个日期列乘 10 万条记录）对于 MySQL 表来说非常小，所以我可能只会使用一个包含多个列的表，除非您认为您将添加新类型的日期字段一直都希望有一个更灵活的模式。您只需要确保索引所有将在查询中用于过滤、排序、连接等的字段。

设计还可以通过您想要对数据执行的查询类型来通知。例如，如果您希望您可能希望根据字段组合查询数据（即用户有某个特定日期，但没有另一个日期），那么在单个表上查询可能会更加优化，因为您可以使用一个简单的SELECT ... WHERE查询。使用单独的表，您可能会发现自己需要执行子选择、奇数连接条件或HAVING子句来执行相同类型的查询。

于 2013-02-20T01:15:27.520 回答
1

如果日期非常具体并且用户将填写所有（或大部分）日期，那么我会使用宽表，因为实际编写查询以获取数据更容易。对于垂直表来说，编写一个查询要求所有用户在一个范围内具有 date1 和在一个范围内具有 date2 的查询要困难得多。

如果您知道需要动态创建日期类型的选项，我只会选择更长的表格。

于 2013-02-20T01:16:46.330 回答
0

只要用户 ID 和日期类型 ID 在主表和 user_dates 表上建立索引，我怀疑您在查询时会注意到一个问题。如果您要在任何一种情况下查询整个表，我敢肯定这将需要很长时间（不过主要是发送数据）。在任何一种情况下，单个用户查找都是即时的。

不要为了一些可能的效率提高而牺牲关系；这不值得。

于 2013-02-20T01:14:20.873 回答
0

通常我会采用两种方式：将基本和最常用的属性放在一张表中。制作一个附加属性表，将 rarley used 属性放入其中，然后可以从应用层延迟获取。这样，您就不会在每次获取用户时都进行 JOIN。

于 2013-02-20T01:35:04.697 回答