Question

在最近的几天里，我打电话来替换我公司的前dba 总而言之，该公司负责计量数据存储。也就是说，自1996年以来，已经以不同的方式测量和存储了许多变量（txt，xls，然后访问等）在去年，所有这些数据都必须存储在一个sql db（sql server 2008 r2）中，但我发现了一个奇怪的而不是直截了当的情况在实践中，大约有30个表，每个表具有不同的列数。每列都是一个变量，在我们的数据库中有超过300个变量表的结构类似： id，siteid，date_of_meas，var1，var2，...，varN（复制30次）

首先，变量不是逻辑分组的（压力与温度等等），但最糟糕的是，每次创建一个新的var（取决于实际因素，这里没有什么有趣的讨论），前dba采取行动这条路： 1.在现有表中添加一个新列（...如果一个表已有50列......怎么办？） 2.写数据你可以弄清楚，这种方式在我看来真的很疯狂

我会从头开始重新设计数据结构。情况就是这样：有一个包含所有现有变量的表（添加新变量没问题）我可以使用变量的id号，创建新表（逻辑上对它们进行分组......但总会有很多表）并使用这些外键插入数据。如下所示：

CREATE TABLE [dbo].[MyMeteo](
[id_meteo] [int] IDENTITY(1,1) NOT NULL,
[varid] [int] NOT NULL,
[siteid] [int] NOT NULL,
[date] [smalldatetime] NOT NULL,
[value] [float] NULL,

...

另一个问题是真正庞大的数据量...因为数据每30分钟测量一次，在1年内测量数据为17520或17568。乘以15年，300个变量和200个站点...我在监视sql db是否仍然是正确的选择。非常感谢迭

Answer 1

如下所示：

CREATE TABLE [dbo].[MyMeteo](
[id_meteo] [int] IDENTITY(1,1) NOT NULL,
[varid] [int] NOT NULL,
[siteid] [int] NOT NULL,
[date] [smalldatetime] NOT NULL,
[value] [float] NULL,

...是entity-attribute-value模式的轻微变化。这是一个反 - 模式。

您以前的DBA可能做得对：每次测量一行，每个变量作为一列。如果这意味着50个或更多列，那么这很重要。

如果需要，可以在单独的表中拆分逻辑组。实际上，不要：你会得到更复杂的查询计划和更慢的查询（当按照存储在一个表中的条件进行排序时，通过存储在另一个表中的条件进行排序时，有时会慢得多），即对你的麻烦几乎没有任何好处。 / p>

简单地说，最重要的是挖掘数据是多么简单。在表格之间拆分数据会使情况变得更糟。使用像你正在研究的那样的伪EAV商店会让事情更多更糟糕。

关于最后一点，SQL是正确的选择：160亿行虽然令人印象深刻，但对于现代数据库而言只是小于等级。

Answer 2

如果数据可以静态关联映射，则EAV是反模式。我很不确定是这种情况。

我们似乎在谈论一组变量变量：不仅添加了新的变量，而且我猜有些变量随着时间的推移而不再使用。

拥有数百列意味着每次我想挖掘数据时都会进行单独的静态查询，而在这种情况下，EAV让我可以非常简单地收集，例如，在给定时间段内对variableX的所有测量，非常简单的可重用查询。对变量ID进行索引也可能会加快对数据库的操作，因为具有50列大部分为空的数据库将花费更长的时间进行搜索（除非您索引所有50列，即使它们可能有98％的时间为空）。

在这种情况下，EAV是否是最佳的是有争议的，因为我认为我们并没有所有的信息来决定，但我认为只是说EAV总是反模式并不具有建设性。

SQL数据库重新定位

2 个答案: