Question

我想要存储在数据库中的一些数据（最初在数据文件中）。

数据文件可能有不同的跟踪策略，因此列不同。

跟踪数据A：

NodeID
Date
max_X@9am-10am 
min_X@9am-10am
max_Y@9am-10am 
min_Y@9am-10am
max_speed@9am-10am
min_speed@9am-10am
max_X@10am-11am 
min_X@10am-11am
max_Y@10am-11am 
min_Y@10am-11am
max_speed@10am-11am
min_speed@10am-11am
...

跟踪数据B：

NodeID
Date
avg_X@9am-9:30am 
avg_Y@9am-9:30am 
avg_speed@9am-9:30am
avg_X@10am-10:30am 
avg_Y@10am-10:30am 
avg_speed@10am-10:30am
...

跟踪数据C：

NodeId
Date
avg_X@the.whole.day
avg_Y@the.whole.day
min_X@the.whole.day
max_X@the.whole.day
min_Y@the.whole.day
max_Y@the.whole.day
sum_MovingDistance@the.whole.day
avg_Speed@the.whole.day

简而言之，一个数据文件在给定的一天以不同的时间间隔存储某个节点的位置范围，速度。在数据文件之外存在区域层次结构，例如，国家：US

然后，每个跟踪数据都有两个版本，一个是历史版，一个是实时版。历史包含汇总数据，它们不会更改。在时间推进期间生成实时数据。当时间没有达到时间间隔时，没有值（NA）。当时间在一个时间间隔内时，每次生成实时数据文件时，值都会改变。

所以我有一些选择

一：在不同的表中存储不同类型的数据文件，数据库表的列可以匹配数据文件中的列。这将导致许多talbes，这通常是一件应该避免的坏事吗？

二：在一个表中对数据文件进行处理。像

这样的事情

Area, NodeID, TrackingStratygy, VarName,             Value    DataType    recordTime  
US    KKEA1   A                 max_X@9am-10am        ??      real-time   09:55@20111203
US    KKEA1   B                 avg_X@9am-9:30am      ??      real-time   09:55@20111203
US    KKEA1   C                 avg_Y@the.whole.day   ??      daily       00:00@20111202

问题在于区域，nodeID，跟踪stratyge和varname的大量复制。

欢迎任何评论和意见。

感谢。

Answer 1

您需要做的第一件事是找出您想要的最终结果。想必是某种报道？

最终结果是否需要以相同格式显示所有内容（历史/新内容）？

历史数据是否会被归档？

新数据是以不同格式生成的，是数据库必须反映的业务要求吗？

我确定还有其他问题......

如果以不同格式生成新数据;并且您需要报告这些格式，然后最简单的（不一定是最好的）选项是使用多个表（如果不是多个数据库实例）。

如果要标准化报告，则需要查看每种格式中复制的字段，以及可以从源数据创建的字段，这些字段不是精确副本。然后它成为一个规范化任务，为不匹配的数据提供单独的表。

您的示例“两个：将数据文件存储在一个表中”是可怕的。如果您沿着这条路走下去，那么就可以将任何事情标准化 - 例如Area，NodeID等。

最终，就我而言，这是一个业务逻辑问题，而不是数据库问题。了解需求是什么，并为数据库建模，以便为最终用户尽可能简单地检索数据，而不会影响您可能拥有的任何安全/存储/业务规则。

Answer 2

选项一将是“官方”方法;只要你可以通过组合表中的条目来重新构造行，你就会很好（尽管加入表需要花费时间/精力）。

选项二看起来更适合拥有DYNAMIC字段集。对于你所描述的，我认为它的方式太灵活了为你需要的东西带来太多的开销。

另一种选择是拥有一个包含所有可能字段的表，其中一些字段对于某些记录是空的。这在空间方面有点低效，但避免了必须加入记录的开销。如果这些字段不多，而且没有那么多带有这些字段的记录，那么开销可能只值1个表来处理，并避免连接。

Answer 3

如果您可以摆动它，将传入的数据更改为此格式可能是最好的：

Tracking_Data
====================
nodeId  -- along with locationTrackedInstant, the unique PK
locationTrackedInstant -- timestamp, in terms of UTC
xPosition  -- whatever your RDBMS uses for location info, and dependent on scale
yPosition
areaId -- Only use if x/y aren't GPS coordinates, as I suspect they may be.

这将允许您提取您想要的任何信息，比您当前的数据更好（例如，09:30到10:30之间的平均速度是多少？）。它可能需要最少的空间来存储所有选项，尽管您将为聚合函数丢失一点处理时间（但如果您的RDBMS具有物化视图，则可以将其交换回来）

您可以几乎将其重组为一个如下所示的表：

Tracking_Data          -- why, oh why, are these at different resolutions?
                       -- and seperated?  They measure the same things...
======================
nodeId
aggregatePeriodStart  -- timestamp
periodDurationInSeconds  -- only due to aggregates.  Alternate units possible.
min_X
max_X
avg_X
min_Y
max_Y
avg_Y
max_Speed
min_Speed
avg_Speed
distance_travelled

然而，你有不同分辨率的数据 - 至关重要的是，最大/最小值的分辨率更高分辨率（反之则不是问题）。遗憾的是，您无法推断出“丢失”的数据，因为它实际上并不正确。所以，你会遇到一些类似的表格：

Tracking_Data_A
====================
nodeId
aggregatePeriodStart  -- timestamp
perdiodDurationInHours
min_X
max_X
min_Y
max_Y
min_Speed
max_Speed

Tracking_Data_B
===================
nodeId
aggregatePeriodStart  -- timestamp
periodDurationInMinutes
avg_X
avg_Y
avg_Speed

Tracking_Data_C
===================
nodeId
aggregateDate  -- date, not timestamp
min_X
max_X
avg_X
min_X
max_X
avg_Y
avg_Speed
distanceTravelled

与包含的实际数据的开销相比，每个表的开销很小。尽管EAV表具有“灵活性”，但你最终会得到怪物语句来重建任何东西;他们也没有正确索引或排序哦，不要忘记限定你的单位 - 特别是速度和距离（英里对公里）。

存储具有许多不同列的不同类型的数据文件（历史和实时）的数据库模式

3 个答案: