存储各种传感器类型的传感器数据
Storing sensor data for various sensor types
我有一个问题，当传感器类型不同时，如何最好地存储产生的传感器数据。
一些背景知识：
我有两个不同的传感单元。
一个单元（比如 A 型单元）内置传感器（温度、湿度等）并按固定顺序生成长度为 12 的 CSV 字符串，其中所有 12 个值对我都有用。
另一个单元（单元类型 B）是一个可以插入探针和能量监控夹等的单元，在所有情况下它都会生成一个长度为 13 的 CSV 字符串，但是如果你只连接了两个东西，你仅从 13 个 CSV 值中的两个获取有用信息。我们将使用该装置的两种不同配置。
所有传感器都有一个 ID（在 CSV 字符串中给出），我将通过 ID link将传感器发送到数据库中已有的房间（SQL 2016）通过网络 UI (ASP.NET).
我将要进行的查询类型是 "what is the current temp in room a"，我还需要查询趋势，例如 "give me all the rooms with a high humidity average"。
我的问题
考虑到目前我将有大约 250 个传感器，每个传感器 post 大约每 10 秒左右通过网络 API，我目前有两种不同类型的 CSV 字符串（将来可能会更多），并且在一种情况下，CSV 字符串将在 CSV 字符串的不同部分包含有用的信息，您会推荐什么作为 suitable table 结构来支持这个？理想情况下在 SQL 服务器中（也许 2016 年 JSON 支持？）因为 SQL 服务器是我更熟悉的东西，但是如果这是一个糟糕的选择，我当然愿意接受你的想法。
我试图避免 table 'per sensor type'，因为这看起来很乱，如果没有新的 tables 等，它也会使将来添加不同的传感器类型变得更加困难.
我确实考虑过将我的 API 与我的网络应用分开，post 将我的传感器连接到它并让 API 将 CSV 'as is' 存储到数据库中，以及 'sensor type' ID。然后我想我可以 post 使用存储过程分批处理它（某种服务）以分批插入我的主数据库，因为我认为这可能会减少一些 API 开销。
数据库结构
一栋楼有很多房间，一个房间有很多传感器。传感器有一个类型。我将在映射 table 中记录房间和传感器 ID 之间的映射。
传感器类型说明
传感器类型 A 具有以下信息：
- 日期（字符串）
- 时间（字符串）
- 传感器 ID（字符串）
- 温度（十进制）
- 湿度（十进制）
- PIR 计数（整数）
传感器 B 有两种不同的配置，在这两种情况下，相同的 CSV 字符串是 posted，不同的是从中使用的值，但我想存储：
配置 1（管道温度）
- 日期时间（unix 时间戳）
- 传感器 ID
- 管道温度 1（十进制）
- 管道温度 2（十进制）
配置2（电源监控）
- 日期时间（unix 时间戳）
- 传感器 ID（字符串）
- 1 的幂（十进制）
- 2 的幂（十进制）
- 3 的幂（十进制）
- 4 的幂（十进制）
所有传感器都有相同的公共数据：
- 日期时间
- 传感器 ID
我想一个解决方案是让一个房间在配置 1 中有许多“传感器类型 A”和许多传感器类型 b，在配置 2 中有许多传感器类型 b，每个传感器类型都有自己的 table对于它的数据，但是我认为如果我可以只为传感器 table 中的所有传感器提供一个 table，并从类型 table 中给它们一个类型，那就太好了这样会更灵活 if/when 添加更多传感器。这种方法的缺点是我什么时候 link 这些不同的传感器数据 types/shapes
谢谢
你的基本选项是discussed in this question，但是这个例子很有趣。
好的，让我们一点一点地进行。
A building has many rooms
马上，我们知道我们有两个 tables:
Building
和
Room
--fk to Building
a room has many sensors.
Sensor
--fk to Room
（或者，如果传感器可能监视来自多个房间的事件）
Sensor
Room_Sensor
--fk to Room
--fk to Sensor
A sensor has a type.
Sensor
--type id of some sort (manufacturer?)
Sensor type A has the following information:
... 这就是它变得有趣的地方。因为，虽然Type A生成这个信息是真的，但这不是Type A的状态；这是 room.
的状态
这就是其中的重要部分：数据库是状态（这里是一系列状态，假设我们有时间戳）的存储库。
还有一个额外的问题 - 如果传感器移动或房间被细分（"adding" 两个或更多以前不存在的房间）会发生什么？那么让我们回溯一下：
Room
--fk to building
Sensor
--type id of some sort, manufacturer info?
Room_Sensor
--pk
--fk to room
--fk to sensor
--createdAt timestamp
请注意，Room_Sensor 可能具有相同 (Room, Sensor) 关系的多个副本，随着时间的推移而变化（也许传感器在走廊上移动了一个星期左右）。
现在，测量数据呢？你这里其实有几个不同的"things"：
Environment
--fk to Room_Sensor
--occurredAt timestamp
--temperatureInCelsius
--humidityInBar (or whatever other unit)
--PIR (particulate? please label your units)
（我假设 Type B 的索引项表示不同 事物 的相同 测量值 ，它们是应该是多行，这意味着额外的 table 用于外键。如果它们是同一事物的不同测量值 - 流入和流出温度，比如说 - 它更简单）
Pipe
Pipe_Temperature
--fk to pipe
--fk to Room_Sensor
--occurredAt timestamp
--temperatureInCelsius
和
Electrical_Drop
Electrical_Drop_Draw
--fk to Electrical_Drop
--fk to Room_Sensor
--occurredAt timestamp
--consumptionInWatts
...是的，这可能就是我要开始的。对于这种结构，传感器的实际物理类型无关紧要——我们只关心它提供给我们的信息类型。也许将来 Type B 会增加测量室温的新功能；如果是这样，数据库可能会保持不变，并且行可能会添加到现有的 tables.
请注意，这样做需要您有一个 API 或某种加载程序，但无论如何您很可能需要其中之一。
我有一个问题，当传感器类型不同时，如何最好地存储产生的传感器数据。
一些背景知识：
我有两个不同的传感单元。
一个单元（比如 A 型单元）内置传感器（温度、湿度等）并按固定顺序生成长度为 12 的 CSV 字符串，其中所有 12 个值对我都有用。
另一个单元（单元类型 B）是一个可以插入探针和能量监控夹等的单元，在所有情况下它都会生成一个长度为 13 的 CSV 字符串，但是如果你只连接了两个东西，你仅从 13 个 CSV 值中的两个获取有用信息。我们将使用该装置的两种不同配置。
所有传感器都有一个 ID（在 CSV 字符串中给出），我将通过 ID link将传感器发送到数据库中已有的房间（SQL 2016）通过网络 UI (ASP.NET).
我将要进行的查询类型是 "what is the current temp in room a"，我还需要查询趋势，例如 "give me all the rooms with a high humidity average"。
我的问题
考虑到目前我将有大约 250 个传感器，每个传感器 post 大约每 10 秒左右通过网络 API，我目前有两种不同类型的 CSV 字符串（将来可能会更多），并且在一种情况下，CSV 字符串将在 CSV 字符串的不同部分包含有用的信息，您会推荐什么作为 suitable table 结构来支持这个？理想情况下在 SQL 服务器中（也许 2016 年 JSON 支持？）因为 SQL 服务器是我更熟悉的东西，但是如果这是一个糟糕的选择，我当然愿意接受你的想法。
我试图避免 table 'per sensor type'，因为这看起来很乱，如果没有新的 tables 等，它也会使将来添加不同的传感器类型变得更加困难.
我确实考虑过将我的 API 与我的网络应用分开，post 将我的传感器连接到它并让 API 将 CSV 'as is' 存储到数据库中，以及 'sensor type' ID。然后我想我可以 post 使用存储过程分批处理它（某种服务）以分批插入我的主数据库，因为我认为这可能会减少一些 API 开销。
数据库结构
一栋楼有很多房间，一个房间有很多传感器。传感器有一个类型。我将在映射 table 中记录房间和传感器 ID 之间的映射。
传感器类型说明
传感器类型 A 具有以下信息：
- 日期（字符串）
- 时间（字符串）
- 传感器 ID（字符串）
- 温度（十进制）
- 湿度（十进制）
- PIR 计数（整数）
传感器 B 有两种不同的配置，在这两种情况下，相同的 CSV 字符串是 posted，不同的是从中使用的值，但我想存储：
配置 1（管道温度）
- 日期时间（unix 时间戳）
- 传感器 ID
- 管道温度 1（十进制）
- 管道温度 2（十进制）
配置2（电源监控）
- 日期时间（unix 时间戳）
- 传感器 ID（字符串）
- 1 的幂（十进制）
- 2 的幂（十进制）
- 3 的幂（十进制）
- 4 的幂（十进制）
所有传感器都有相同的公共数据：
- 日期时间
- 传感器 ID
我想一个解决方案是让一个房间在配置 1 中有许多“传感器类型 A”和许多传感器类型 b，在配置 2 中有许多传感器类型 b，每个传感器类型都有自己的 table对于它的数据，但是我认为如果我可以只为传感器 table 中的所有传感器提供一个 table，并从类型 table 中给它们一个类型，那就太好了这样会更灵活 if/when 添加更多传感器。这种方法的缺点是我什么时候 link 这些不同的传感器数据 types/shapes
谢谢
你的基本选项是discussed in this question，但是这个例子很有趣。
好的，让我们一点一点地进行。
A building has many rooms
马上，我们知道我们有两个 tables:
Building
和
Room
--fk to Building
a room has many sensors.
Sensor
--fk to Room
（或者，如果传感器可能监视来自多个房间的事件）
Sensor
Room_Sensor
--fk to Room
--fk to Sensor
A sensor has a type.
Sensor
--type id of some sort (manufacturer?)
Sensor type A has the following information:
... 这就是它变得有趣的地方。因为，虽然Type A生成这个信息是真的，但这不是Type A的状态；这是 room.
这就是其中的重要部分：数据库是状态（这里是一系列状态，假设我们有时间戳）的存储库。
还有一个额外的问题 - 如果传感器移动或房间被细分（"adding" 两个或更多以前不存在的房间）会发生什么？那么让我们回溯一下：
Room
--fk to building
Sensor
--type id of some sort, manufacturer info?
Room_Sensor
--pk
--fk to room
--fk to sensor
--createdAt timestamp
请注意，Room_Sensor 可能具有相同 (Room, Sensor) 关系的多个副本，随着时间的推移而变化（也许传感器在走廊上移动了一个星期左右）。
现在，测量数据呢？你这里其实有几个不同的"things"：
Environment
--fk to Room_Sensor
--occurredAt timestamp
--temperatureInCelsius
--humidityInBar (or whatever other unit)
--PIR (particulate? please label your units)
（我假设 Type B 的索引项表示不同 事物 的相同 测量值 ，它们是应该是多行，这意味着额外的 table 用于外键。如果它们是同一事物的不同测量值 - 流入和流出温度，比如说 - 它更简单）
Pipe
Pipe_Temperature
--fk to pipe
--fk to Room_Sensor
--occurredAt timestamp
--temperatureInCelsius
和
Electrical_Drop
Electrical_Drop_Draw
--fk to Electrical_Drop
--fk to Room_Sensor
--occurredAt timestamp
--consumptionInWatts
...是的，这可能就是我要开始的。对于这种结构，传感器的实际物理类型无关紧要——我们只关心它提供给我们的信息类型。也许将来 Type B 会增加测量室温的新功能；如果是这样，数据库可能会保持不变，并且行可能会添加到现有的 tables.
请注意，这样做需要您有一个 API 或某种加载程序，但无论如何您很可能需要其中之一。