6 张表讲透 WiFi-DensePose 数据库设计姿态数据存储完整指南【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuViewWiFi-DensePose 用普通路由器就能穿墙识别人体姿态但信号变成姿态之后这条实时数据流谁来接住答案藏在它的数据库设计里6 张表、按数据旅程分工。本文带你沿信号→CSI→姿态的完整流转拆解这套姿态数据存储与 CSI 数据管理的架构看懂每张表为什么存在、关键设计为什么这么选。数据从哪来先走一遍完整旅程打开模型清单之前先跟着一条数据跑一圈——这比逐表罗列更能帮你建立直觉设备注册路由器/传感器先入库建档MAC 地址、坐标、状态写进devices。开启采集一次采集行动开一个值班记录本——sessions表记下起止时间、设备外键、已收帧数就像执勤台账。原始信号落库路由器吐出的 CSI 帧各子载波的幅度相位高频写入csi_data先标pending等模型去消费。姿态结果落库模型跑完关键点、置信度写进pose_detections与原始帧通过会话和时间戳对齐。你会发现原始层csi_data和结果层pose_detections之间隔着一条处理状态的流水线而不是混在一张大表里。六张表各管一摊表名一句话角色存什么关键设计devices设备档案柜MAC、IP、三维坐标、状态MAC 唯一约束 状态枚举校验sessions采集值班记录本起止时间、帧数统计、配置外键指向设备级联删除csi_data原始信号仓幅度/相位数组、频率、处理状态FloatArray 列 纳秒时间戳pose_detections姿态结果库关键点、边界框、置信度JSON 存变长结构system_metrics系统体检表指标名、数值、标签按名称/来源/时间建索引audit_logs审计黑匣子事件类型、操作者、前后状态快照before/after 双 JSON 列前三张是数据主干后两张是旁路一个管系统健康一个管操作留痕。三个值得推敲的设计决策姿态关键点为什么直接塞 JSON每帧可能检出 1 个人也可能 5 个每个人的关键点数量还随模型版本变。如果拆成keypoints子表外键和行数都会爆炸而且查询时还要再 join 一次。于是keypoints和bounding_boxes直接存成 JSON 列——整帧结果一次读出模型升级时结构自由伸缩。代价是没法对单个关节做 SQL 过滤但这类细粒度分析本来就该交给下游不是数据库的活。class PoseDetection(Base, UUIDMixin, TimestampMixin): __tablename__ pose_detections frame_number Column(Integer, nullableFalse) timestamp_ns Column(Integer, nullableFalse) session_id Column(UUID(as_uuidTrue), ForeignKey(sessions.id), nullableFalse) person_count Column(Integer, default0, nullableFalse) keypoints Column(JSON, nullableTrue) # 每人一组关键点 bounding_boxes Column(JSON, nullableTrue) detection_confidence Column(Float, nullableTrue) processing_time_ms Column(Float, nullableFalse) # 处理耗时CSI 幅度相位为什么用数组列一帧 CSI 有几十个乃至上百个子载波每个都有幅度和相位。若一个子载波一行数据量瞬间膨胀几个数量级还会把天然属于同一帧的数据打散。WiFi-DensePose 的选择是FloatArray一帧一行幅度相位各占一列紧凑且能整帧读取。同时timestamp_ns精确到纳秒——无线信号的抖动是微秒级的毫秒时间戳根本排不好序。class CSIData(Base, UUIDMixin, TimestampMixin): __tablename__ csi_data sequence_number Column(Integer, nullableFalse) timestamp_ns Column(Integer, nullableFalse) # 纳秒级时间戳 amplitude Column(FloatArray, nullableFalse) # 各子载波幅度 phase Column(FloatArray, nullableFalse) # 各子载波相位 frequency Column(Float, nullableFalse) # MHz num_subcarriers Column(Integer, nullableFalse) processing_status Column(String(20), defaultpending)审计日志为什么单独建表把操作记录塞进业务表是最省事的偷懒但业务表要删要改痕迹就没了。audit_logs单独存在每次关键操作记下谁user_id、动哪个资源resource_type/id、改了什么before_state/after_state两份 JSON 快照。只增不改的黑匣子出了数据问题可以逐帧回放。让数据既可靠又快约束这样加脏数据进不来数据库层面用CheckConstraint把范围钉死状态只能取枚举值、person_count 0、confidence必须在 0 到 1 之间、frequency 0。再配一个唯一约束(device_id, sequence_number, timestamp_ns)同一设备的同一帧不可能重复入库——高频写入场景下防重比事后去重便宜得多。索引这样建查询更快索引完全对着查询模式建按设备回溯、按会话拉数据、按时间窗切片、按处理状态扫队列每个高频路径各有一个专属索引。__table_args__ ( Index(idx_csi_device_id, device_id), Index(idx_csi_session_id, session_id), Index(idx_csi_timestamp, timestamp_ns), Index(idx_csi_processing_status, processing_status), UniqueConstraint(device_id, sequence_number, timestamp_ns, nameuq_csi_device_seq_time), )时间戳与分区时间轴的双保险所有表继承TimestampMixincreated_at/updated_at由数据库默认值自动维护不用应用层操心。system_metrics还在created_at上加了索引——监控查询天然按时间走。对于csi_data这类只增、按时间检索的巨表进一步的做法是按时间分区查今天上午只扫一个分区删旧数据直接 drop 分区比逐行 DELETE 快几个量级。回看这套设计的核心思想让数据沿旅程分表、变长结构交给 JSON、可靠性下沉到约束、速度交给索引——每张表只干一件事查询路径与索引一一对应。完整的 6 张表模型定义可以直接读 archive/v1/src/database/models.py逐字段验证本文说的每个决策。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 6 张表讲透 WiFi-DensePose 数据库设计：姿态数据存储完整指南
6 张表讲透 WiFi-DensePose 数据库设计姿态数据存储完整指南【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuViewWiFi-DensePose 用普通路由器就能穿墙识别人体姿态但信号变成姿态之后这条实时数据流谁来接住答案藏在它的数据库设计里6 张表、按数据旅程分工。本文带你沿信号→CSI→姿态的完整流转拆解这套姿态数据存储与 CSI 数据管理的架构看懂每张表为什么存在、关键设计为什么这么选。数据从哪来先走一遍完整旅程打开模型清单之前先跟着一条数据跑一圈——这比逐表罗列更能帮你建立直觉设备注册路由器/传感器先入库建档MAC 地址、坐标、状态写进devices。开启采集一次采集行动开一个值班记录本——sessions表记下起止时间、设备外键、已收帧数就像执勤台账。原始信号落库路由器吐出的 CSI 帧各子载波的幅度相位高频写入csi_data先标pending等模型去消费。姿态结果落库模型跑完关键点、置信度写进pose_detections与原始帧通过会话和时间戳对齐。你会发现原始层csi_data和结果层pose_detections之间隔着一条处理状态的流水线而不是混在一张大表里。六张表各管一摊表名一句话角色存什么关键设计devices设备档案柜MAC、IP、三维坐标、状态MAC 唯一约束 状态枚举校验sessions采集值班记录本起止时间、帧数统计、配置外键指向设备级联删除csi_data原始信号仓幅度/相位数组、频率、处理状态FloatArray 列 纳秒时间戳pose_detections姿态结果库关键点、边界框、置信度JSON 存变长结构system_metrics系统体检表指标名、数值、标签按名称/来源/时间建索引audit_logs审计黑匣子事件类型、操作者、前后状态快照before/after 双 JSON 列前三张是数据主干后两张是旁路一个管系统健康一个管操作留痕。三个值得推敲的设计决策姿态关键点为什么直接塞 JSON每帧可能检出 1 个人也可能 5 个每个人的关键点数量还随模型版本变。如果拆成keypoints子表外键和行数都会爆炸而且查询时还要再 join 一次。于是keypoints和bounding_boxes直接存成 JSON 列——整帧结果一次读出模型升级时结构自由伸缩。代价是没法对单个关节做 SQL 过滤但这类细粒度分析本来就该交给下游不是数据库的活。class PoseDetection(Base, UUIDMixin, TimestampMixin): __tablename__ pose_detections frame_number Column(Integer, nullableFalse) timestamp_ns Column(Integer, nullableFalse) session_id Column(UUID(as_uuidTrue), ForeignKey(sessions.id), nullableFalse) person_count Column(Integer, default0, nullableFalse) keypoints Column(JSON, nullableTrue) # 每人一组关键点 bounding_boxes Column(JSON, nullableTrue) detection_confidence Column(Float, nullableTrue) processing_time_ms Column(Float, nullableFalse) # 处理耗时CSI 幅度相位为什么用数组列一帧 CSI 有几十个乃至上百个子载波每个都有幅度和相位。若一个子载波一行数据量瞬间膨胀几个数量级还会把天然属于同一帧的数据打散。WiFi-DensePose 的选择是FloatArray一帧一行幅度相位各占一列紧凑且能整帧读取。同时timestamp_ns精确到纳秒——无线信号的抖动是微秒级的毫秒时间戳根本排不好序。class CSIData(Base, UUIDMixin, TimestampMixin): __tablename__ csi_data sequence_number Column(Integer, nullableFalse) timestamp_ns Column(Integer, nullableFalse) # 纳秒级时间戳 amplitude Column(FloatArray, nullableFalse) # 各子载波幅度 phase Column(FloatArray, nullableFalse) # 各子载波相位 frequency Column(Float, nullableFalse) # MHz num_subcarriers Column(Integer, nullableFalse) processing_status Column(String(20), defaultpending)审计日志为什么单独建表把操作记录塞进业务表是最省事的偷懒但业务表要删要改痕迹就没了。audit_logs单独存在每次关键操作记下谁user_id、动哪个资源resource_type/id、改了什么before_state/after_state两份 JSON 快照。只增不改的黑匣子出了数据问题可以逐帧回放。让数据既可靠又快约束这样加脏数据进不来数据库层面用CheckConstraint把范围钉死状态只能取枚举值、person_count 0、confidence必须在 0 到 1 之间、frequency 0。再配一个唯一约束(device_id, sequence_number, timestamp_ns)同一设备的同一帧不可能重复入库——高频写入场景下防重比事后去重便宜得多。索引这样建查询更快索引完全对着查询模式建按设备回溯、按会话拉数据、按时间窗切片、按处理状态扫队列每个高频路径各有一个专属索引。__table_args__ ( Index(idx_csi_device_id, device_id), Index(idx_csi_session_id, session_id), Index(idx_csi_timestamp, timestamp_ns), Index(idx_csi_processing_status, processing_status), UniqueConstraint(device_id, sequence_number, timestamp_ns, nameuq_csi_device_seq_time), )时间戳与分区时间轴的双保险所有表继承TimestampMixincreated_at/updated_at由数据库默认值自动维护不用应用层操心。system_metrics还在created_at上加了索引——监控查询天然按时间走。对于csi_data这类只增、按时间检索的巨表进一步的做法是按时间分区查今天上午只扫一个分区删旧数据直接 drop 分区比逐行 DELETE 快几个量级。回看这套设计的核心思想让数据沿旅程分表、变长结构交给 JSON、可靠性下沉到约束、速度交给索引——每张表只干一件事查询路径与索引一一对应。完整的 6 张表模型定义可以直接读 archive/v1/src/database/models.py逐字段验证本文说的每个决策。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考