问题描述
从“Web网站”和“手机App”上控制设备的“启停”、“变频”。这样的实现思路行不行？？？“Web网站”和“手机App”——>控制指令更新到数据库——>Socket程序传输控制指令——>更新到控制设备本地数据库——>控制设备读取本地数据库进行控制这样的控制思路有没有问题？？？有三个弊端：1、所有的控制指令都走数据库，控制指令传输速度比较慢。2、控制指令下达之后的设备状态不易返回。3、数据采集是5分钟一次，但是控制指令的检索是秒级以下的。
解决方案
解决方案二：
你在web服务上运行socket,直接TCP跟设备通信,就不用走数据库了
解决方案三：
你控制设备的这个东西跟服务器之间是如何连接的?采用什么模式?MQTT还是http还是自己的tcp/ip还是单纯的设备端定时器发送http请求看是否有控制命令实现控制?条件不足无法作答..
解决方案四：
控制计划50*20*7，每天都有，怎么设备比较好呢？？？
解决方案五：
引用2楼diaodiaop的回复:
你控制设备的这个东西跟服务器之间是如何连接的?采用什么模式?MQTT还是http还是自己的tcp/ip还是单纯的设备端定时器发送http请求看是否有控制命令实现控制?条件不足无法作答..
TCP/IP来连接的。
解决方案六：
既然你的设备跟服务使用tcp/ip那就好办了啊.网页或者是app调用webservice..然后webservice中给本机(127.0.0.1:XXXX)发送命令本机服务XXXX能收到命令(当然这里面有设备发送的也有webservice发送的.你可以通过协议判断也可以通过IP..)如果这个命令是来自web,那么解析下需要控制哪个控制的命令是什么.然后从你的"集合"中找到该设备..进行数据发送就OK了.. 注:集合表示你设备列表.
解决方案七：
控制程序设计的核心，跟你的数据库扯不上关系，不是什么insert+select语句。如果你不删除数据库的纠结，你就不能先把控制的核心程序设计出来。比如说爱迪生发明电灯，贝尔发明电话的时候，他们想的是给市政公司做“增删改查”用的？当你做一个比较“酷”的应用的时候，你满脑子都是上学时最没有技术门槛、最低级的“数据库”，那么除了做骗国营单位的OA，做别的就不行了。
解决方案八：
设计这样的系统，你应该了解一下（比如说）微信、飞信是如何连接服务器的。然后你的web网站也作为一个终端（只不过不是手机、而是asp.net网站）而已。所有东西都是直截了当的，先把体验到性能的、直接连通的、真正该学习的技术走通，避免沉浸在无关的那些入门书上的“增删改查”中。
解决方案九：
引用6楼sp1234的回复:
控制程序设计的核心，跟你的数据库扯不上关系，不是什么insert+select语句。如果你不删除数据库的纠结，你就不能先把控制的核心程序设计出来。比如说爱迪生发明电灯，贝尔发明电话的时候，他们想的是给市政公司做“增删改查”用的？当你做一个比较“酷”的应用的时候，你满脑子都是上学时最没有技术门槛、最低级的“数据库”，那么除了做骗国营单位的OA，做别的就不行了。
控制还有另外一种情况啊。。。根据计划进行数据控制，这个是必须要存储在本地数据库里面的吧。
解决方案十：
所谓通信,不要仅仅局限在数据库通信上面数据库不过相当于共享硬盘而已,是效率最低的一种方式
解决方案十一：
而且压根没看出来有什么必要弄两套数据库为什么服务器上有数据库,设备本地还要有数据库
解决方案十二：
我无法看出你的所谓“设备”跟其它东西的组成架构，而且我估计你目前也到不了那个程度，所以没有提及。作为一个简单的起步，你先应该搞懂“在网页上输入几排信息，然后分别把每条信息发给不同的手机”这个怎么完成。通过这个模式，让你自己先在初步的架构上——最基本的控制指令即时传输上——了解一些“跟得上时代”的一些前后台系统设计知识，而不是只是知道如何访问数据库。应用程序首先要完成通讯功能，其次（已经跑起来以后）才引入了官僚功能而逐步需要一些“增删改查”（而且这也是前端需求驱动的）。如果你不知道如何通讯，你就不能进入类似的领域去先期设计什么程序，这个时候就不要空想。
解决方案十三：
任何地方都可以用到数据库。web服务器可以用到，应用服务器可以用到，手机服务器可以用到，你的上位机可以用到，甚至设备里边也可以用到嵌入式的数据库。问题是，以“可能用到数据库”这个为借口，你要达到什么目的？难道你设计一个程序不是为了实际研发出来一个真正有用、能用、符合最近20年行业技术规范的产品，而是为了让不懂研发的老板多发你几个月工资的么？
解决方案十四：
引用8楼tongji0009的回复:
控制还有另外一种情况啊。。。根据计划进行数据控制，这个是必须要存储在本地数据库里面的吧。
当你还不知道一个基本的控制系统的原理的时候，你搬出这个借口来，损失的不是我，是你自己的项目。
解决方案十五：
不过还是得支持楼主一下：楼主是想做智能家居远程控制呀。——WEB发送的指令数据，除非你能在30秒内传给远程设备；否则，很容易超时丢失——存库是求稳的做法。但是，存库的话：WEB确实不能实时看到指令的处理结果：用户体验不大好。
其他方案：
引用10楼Z65443344的回复:
而且压根没看出来有什么必要弄两套数据库为什么服务器上有数据库,设备本地还要有数据库
问题：采集到的数据先存储在本地设备，然后从本地没五分钟一次传到数据中心。这样可以防止网络中断，造成数据缺失
其他方案：
本地设备适当的存储终端信息是必要的，在网络中断、终端宕机时进行数据暂存
其他方案：
引用11楼sp1234的回复:
我无法看出你的所谓“设备”跟其它东西的组成架构，而且我估计你目前也到不了那个程度，所以没有提及。作为一个简单的起步，你先应该搞懂“在网页上输入几排信息，然后分别把每条信息发给不同的手机”这个怎么完成。通过这个模式，让你自己先在初步的架构上——最基本的控制指令即时传输上——了解一些“跟得上时代”的一些前后台系统设计知识，而不是只是知道如何访问数据库。应用程序首先要完成通讯功能，其次（已经跑起来以后）才引入了官僚功能而逐步需要一些“增删改查”（而且这也是前端需求驱动的）。如果你不知道如何通讯，你就不能进入类似的领域去先期设计什么程序，这个时候就不要空想。
我做的采集系统很稳定啊，3000多个点，5分钟一条数据，运行的么有问题。从数据采集，网络传输，数据处理并行计算，再到Webapp的数据展示，都无有问题。。。只是没做过控制，控制指令的传输频率有比较高。
其他方案：
引用13楼sp1234的回复:
Quote: 引用8楼tongji0009的回复:
控制还有另外一种情况啊。。。根据计划进行数据控制，这个是必须要存储在本地数据库里面的吧。当你还不知道一个基本的控制系统的原理的时候，你搬出这个借口来，损失的不是我，是你自己的项目。
是没做过太多的控制系统，所以想请教下啊。
其他方案：
通讯一定要即时，这样用户体验才好。数据库用来存储即时通讯的历史信息即可。