Question

我需要每天存储96个数据（每15分钟1个数据）。我看到有两个明显的解决方案，但我不知道选择哪个。我可以按行（= 96条记录+ ID）或按列（= 1条记录，96条col + ID）存储每个数据。这是一个重要的问题，因为它是我数据库的根设计问题。

我想知道在进行查询和连接时哪一个会更快（考虑到索引是否正确创建）？将所有数据存储在单个记录中还是存储在多个记录中？

处理96个cols并对它们进行操作（将一个记录与另一个记录相乘或总结一整天）非常痛苦。然而，它使得人类（=开发人员）对数据的读取更容易。

有没有人有这方面的经验？

Answer 1

我不知道你想对这些数据做什么，但是假设你想要对特定日期的所有数据求和。如果使用关系表，则查询为：

select  sum(field1) 
from table1 t 
where t.date = '20141213'

但是如果你想为非关系设计做同样的事情，你必须写

select field1+field2+field3+...field96 from table1

如果您需要其他聚合，代码会变得更糟：

select Count(field1)
from
(select field1  from table1 where date = '20141213' and field1 is not null
union all
select field2  from table1 where date = '20141213' and field2 is not null
union all
select field3  from table1 where date = '20141213' and field3 is not null
... ( put in a separate stement for each field)
union all
select field96  from table1 where date = '20141213' and field96 is not null

）a

如果您以后需要经常插入两次，则需要添加96个列并修复针对它编写的所有代码。根据每列中的数据大小，您可能会遇到单个记录的记录限制。

考虑到这一点，我不认为96列是个好主意。

Answer 2

我建议第一个解决方案：96条记录（+ ID）/天，因为它是一个重复发生的数据捕获过程，可能数据类似（换句话说，15分钟基础值的属性不会改变）
优点：
- 如果数据捕获间隔增加或减少，则您不需要更改表结构 - 如果您以后需要添加其他属性（例如捕获的时间戳，谁捕获数据等），那么它更容易使用。
- 每天96行不是那么大的数据量（每年大约35k），所以如果你在ID列上有一个聚集索引，那么查询成本不应该太高，即使从长期来看也是如此。

Answer 3

我们没有足够的信息来决定正确的设计。

在做出任何决定之前，请花更多时间处理将存在于数据库中的数据，并确定不同值之间存在的任何关系。您知道存储后数据的使用方式吗？与开发人员交谈，但不要设计，唯一的目标是让开发人员轻松使用。

只有一张桌子没有任何问题，但你描述的问题让我觉得它不是最好的解决方案。

最后一点，如果“按列”表示实体 - 属性 - 值模型 - 该设计应保留给需要存储的值的数量和类型将要更改的环境。查询效率低下。我很自在地说，即使这里的信息有限，你也应该远离那个设计。

Answer 4

您能否根据包含96条记录的1列形成关系？

这里存在巨大的设计缺陷。记住SQL Server是一个关系数据库。如果这种关系不是你所需要的，那么从长远来看，你只会让人类更加困难。您的解决方案应该是可扩展的。

您无法规范化基于列的数据存储结构，这会破坏数据库固有的性能功能。另外，如何使用索引？

我认为应首先理解对这种关系的坚定理解。

此外，您可以从这些列中获取所需的数据，但有时枢轴/非透视功能对系统而言代价高昂，您肯定会询问开发人员他们希望如何表示这些数据。作为一名开发人员，如果标准查询不起作用并且需要定期查询，这可能会带来很多问题，从长远来看可能并不容易解决。

SQL Server查询速度 - 按记录或按列存储

4 个答案: