📚 课程目录第3章设备属性定义

设备属性定义：静态属性与动态属性、必填属性与可选属性、属性标准化

设备属性这件事，说白了就是给每台设备办一张「身份证」。但很多人把这事想简单了——以为填个设备名称、型号就完事了。我在好几个项目里都见过，设备台账建了半年，结果想查某台设备的固件版本，发现根本没这个字段。嗯，这就是属性定义没做好的典型后果。

这一章，我带你把这套属性体系理清楚。咱们从四个维度来拆：静态 vs 动态、必填 vs 可选，最后落到标准化上。

先问个问题：一台设备的序列号会变吗？不会。那它的运行温度会变吗？当然会。这就是静态和动态最直观的区别。

静态属性，就是设备出厂时就定死的东西。比如：

动态属性，是设备在生命周期里不断变化的数据。比如：

关键原则：静态属性写入一次，原则上不再修改。动态属性需要设计采集频率和更新策略。

我遇到过最头疼的情况是什么？有人把动态属性当静态存。比如设备的「当前负责人」字段，每次人员变动就去改数据库。你想想看，这会导致什么后果？历史追溯全乱了。正确的做法是：负责人应该作为动态属性，或者单独建一个「归属变更记录表」。

这个分类其实是在回答一个问题：录入一台设备时，哪些信息必须给，哪些可以后补？

我个人习惯把属性分成三个等级：

注意：必填属性不是越多越好。我曾经见过一个系统，必填字段设了20多个，结果一线运维人员为了快速录入，随便填了一堆假数据。最后台账反而没法用。

我的建议是：必填属性控制在5个以内。剩下的用「推荐」和「可选」来兜底。你可以在设备注册后，通过定期巡检或批量补录的方式，把推荐属性慢慢补齐。

这是最容易被忽视、但后患最大的一环。什么叫标准化？就是同一个属性，在不同系统、不同部门、不同人嘴里，说的是同一个东西。

举个例子。「设备状态」这个属性，A部门用「正常/异常/报废」，B部门用「运行中/待修/已处置」，C部门直接写「OK/NG」。你想想看，三个系统的数据拉到一起做报表，怎么统计？

标准化的核心就三件事：

实操技巧：我建议你建一个「属性字典表」。把每个属性的名称、数据类型、取值范围、示例值、所属类别都写清楚。这个表就是整个设备管理系统的数据宪法。

下面这张图，把整个属性体系的结构画清楚了：

光说理论没用，我给你一套能直接用的操作流程：

避坑指南：我曾经在一个项目里，直接拿Excel的列名当属性名导入系统。结果「设备编号」和「资产编号」两个字段，在不同Excel里混着用。最后花了整整两周做数据清洗。所以——标准化一定要在系统上线前做完，别指望事后补救。

不同类别的设备，属性差异可能很大。一台服务器和一台打印机，共用一套属性模板显然不合理。我的做法是：设计一个基础模板 + N个扩展模板。

基础模板包含所有设备都有的公共属性：

扩展模板按设备类别定制。比如：

这样设计的好处是：既保证了数据的一致性，又保留了灵活性。你想想看，如果所有设备都用一套模板，要么信息太少不够用，要么字段太多填不完。分层设计刚好解决了这个矛盾。

个人经验：我建议你在设计属性模板时，留一个「自定义属性」的扩展机制。比如允许用户添加键值对。这样遇到特殊设备时，不用每次都改数据库结构。但要注意——自定义属性只能作为补充，核心属性必须走标准化模板。

最后说一句。属性定义这件事，看起来是技术活，其实是管理活。你定义了什么属性，就决定了你能管到什么程度。属性定义得越细，管理粒度就越精细。但也要把握好度——别为了追求完美，把系统搞得太复杂，最后没人愿意用。