iotsharp相关表结构设计

IoTSharp 的数据表结构设计非常灵活，它采用了分层存储和策略可插拔的架构。这意味着它的表结构并非一成不变，而是取决于你在配置文件中选择的存储策略（例如是用于存储设备信息的关系型数据库，还是用于存储海量传感器数据的时序数据库）。

基于 IoTSharp 的架构特性，我为你整理了其核心表结构设计方案，主要分为关系型数据（业务元数据）和时序数据（遥测数据）两大部分。

1. 关系型数据存储（业务元数据）

这部分数据主要存储设备档案、租户信息、用户权限、产品定义等“静态”或“低频”数据。IoTSharp 支持 PostgreSQL、MySQL、SQL Server、SQLite 等多种数据库。

虽然 IoTSharp 使用 Entity Framework Core 自动生成表，但其逻辑结构通常包含以下核心表：

🏢 核心业务表结构示例

表名 (逻辑名)	关键字段	说明
Devices (设备表)	Id (主键), Name, DeviceType, TenantId, CustomerId, Status (在线/离线), LastConnectTime	存储设备的核心身份信息，关联租户和客户。
Tenants (租户表)	Id, Name, CreatorId	多租户隔离的核心，不同租户的数据在逻辑或物理上隔离。
Customers (客户表)	Id, Name, TenantId	隶属于租户之下的业务分组。
Users (用户表)	Id, UserName, PasswordHash, Role, TenantId	平台操作人员，通过角色控制权限。
Products (产品表)	Id, Name, TenantId	用于批量管理设备，设备通常继承产品的属性和遥测定义。
Assets (资产表)	Id, Name, Type	抽象的物理对象，可以由多个设备组合而成（数字孪生概念）。

2. 时序数据存储（遥测数据）

这是 IoTSharp 最复杂的部分。由于传感器数据量极大（高频写入），IoTSharp 提供了多种存储策略，表结构也随之不同。你可以通过 appsettings.json 中的 TelemetryStorage 配置项来切换。

📈 策略 A：关系型数据库分表存储 (Sharding)

如果你选择使用 MySQL、PostgreSQL 或 SQLite 存储遥测数据，IoTSharp 会利用 EFCore.Sharding 组件进行分表。

• 表命名规则：通常按时间（月/日）或哈希自动拆分。例如：TelemetryData_202604。
• 表结构设计：

  CREATE TABLE TelemetryData_202604 (
      Id BIGINT PRIMARY KEY,       -- 主键
      DeviceId UNIQUEIDENTIFIER,   -- 设备ID (外键逻辑)
      Key NVARCHAR(255),           -- 数据键名 (如 "temperature")
      Value NVARCHAR(MAX),         -- 数据值 (通常存为字符串或JSON，兼容不同类型)
      DateTime DATETIME,           -- 时间戳
      -- 索引优化：通常会为 DeviceId 和 DateTime 建立联合索引以加速查询
  );
  

  特点：结构简单，利用关系型数据库事务，但数据量过大时需依赖分表策略。

📉 策略 B：专业时序数据库 (InfluxDB / TDengine)

如果你配置了 InfluxDB 或 TDengine，数据将不再以传统的“行/列”二维表形式存在，而是采用测量（Measurement）模型。

• InfluxDB 结构映射：
  • Measurement: TelemetryData
  • Tag (索引字段): DeviceId (用于快速过滤设备)
  • Field (数据字段): Key (如 "temp"), Value (如 25.5)
  • Timestamp: 自动生成的时间戳
• TDengine 结构映射：
  • 利用 TDengine 的超级表（Super Table）概念，每个设备或每类设备作为一个子表，自动处理时间序列的高效压缩和存储。

3. 事件与告警表

用于记录系统运行中产生的事件、告警和规则引擎触发记录。

• Events (事件表):
  • Id: 主键
  • DeviceId: 关联设备
  • EventType: 事件类型 (如 "HighTempAlarm")
  • Message: 事件详细描述
  • TimeStamp: 发生时间
  • Level: 告警级别 (Info, Warning, Critical)

4. 总结：IoTSharp 数据架构全景

为了让你更直观地理解，我们可以将 IoTSharp 的数据存储看作一个“双轨制”系统：

数据类型	存储位置	推荐数据库	核心表/结构特点
元数据 (设备、用户、规则)	关系型存储层	PostgreSQL / MySQL	标准关系表，强调数据一致性和关联查询。
遥测数据 (温度、电压等)	时序存储层	InfluxDB / TDengine / Sharding	海量写入优化。要么是自动分片的 TelemetryData_ 表，要么是时序数据库的 Measurement。
消息/事件	消息存储	MongoDB / LiteDB / InMemory	用于解耦系统组件，记录瞬时消息。

设计建议：
如果你正在设计基于 IoTSharp 的二次开发或进行数据库规划：

1. 生产环境推荐：使用 PostgreSQL 存储元数据（稳定性好），配合 InfluxDB 或 TDengine 存储遥测数据（写入性能极高）。
2. 开发/测试环境：直接使用 SQLite 并开启 Sharding 模式，零依赖启动，且能模拟分表逻辑。