有报道指出，大家好，我是wacky。上一篇我们聊了通信协议——Modbus和OPC UA怎么选、怎么用、怎么避坑。如果通信协议是"把数据搬过来"，那今天这一篇解决的问题是：数据搬过来之后怎么办。 科技新闻。
这一篇我们聊三件事：数据怎么存、数据怎么访问、业务逻辑怎么设计。对应.NET工控技术栈的第二层——数据与业务层。
原因很实在：工控上位机通常部署在工业PC或触摸屏上，不一定有数据库服务器，也不一定有DBA维护。SQLite是嵌入式数据库，不需要安装服务、不需要配置账号密码、一个文件就是整个数据库，跟着你的程序走。对于大多数单机上位机项目，SQLite完全够用。
数据背景与起因
配置数据和业务数据，首选必须是SQLite。
第一类是配置数据和业务数据——设备信息、用户权限、工单记录、报警历史。这类数据的特点是结构化、需要事务支持、查询条件复杂、数据量可控。说白了就是关系型数据库的活儿。
两类数据用不同的存储方案，别图省事用一个数据库搞定所有事。
数据事件经过
一个工控上位机系统，通信只是第一步。PLC每秒推送几百上千个数据点，你拿到了温度、压力、流量、位置……然后呢？直接显示在界面上？关掉程序就没了。写进文本文件？查询的时候痛苦不堪。更别提那些复杂的业务逻辑——设备运行到什么阶段了、什么时候该报警、报警之后走什么流程——这些都不是通信层能解决的。
第二类是时序数据——传感器采集的温度曲线、电机转速波动、压力趋势。这类数据的特点是写入频繁（每秒成百上千条）、单条数据简单、按时间范围查询、很少修改。这是时序数据库的主场。
工控场景的数据分两类，存储策略完全不同。
数据各方回应
EFCore配合SQLite，NuGet安装Microsoft.EntityFrameworkCore.Sqlite，定义好实体类和DbContext就能跑：
