用数据库(数据结构)来描述真实世界的具体对象----设备，卡，代理商，消费清单，电子钱包

基本表：设备表，卡表，代理商表，消费表，电子钱包表；

设备端：登录，查询设备表，判断设备号是否合法；刷卡，查询卡表判断否合法（在代理商名下卡表查询，多个约束条件查询）；其他包主要与服务器进行数据交互（数据库交互），客户端交互稍后讨论；

客户端：登录查询代理商表，判断手机号是否合法，抽取该代理商名下设备列表where id=188XXXXXXXx，通过代理商id一般是手机号码，查询设备表，符合要求的就可以抽取出来;代理商名下的卡表也是如此，查询卡表，卡表有一个元素就是代理商id了，就可以抽取代理商名下所有卡。

关于充值，拉黑，查询，结算，重置都是操作基本卡表。

修改ip,单价，最大限额，臭氧，广告灯都是操作设备表。

代理商表，设备表目前没有没有注册通道；

卡表有一个自动建卡功能，就是有create卡表的权限了。

大部分都是update设备表，卡表，代理商表通过各种组合查询设备表，卡表-形成视图呈现给客户。

电子水卡，一般是与手机号码绑定的，传统的水卡是8位的，如何把电子水卡与实体卡绑定呢；刷电子水卡实体卡，发送查询包，发现卡表有电子水卡号码，卡内金额加到电子钱包，内卡内金额清零，获取电子卡表金额，下发到设备端。

实体卡绑定电子水卡，先有电子钱包，电子钱包添加实体卡，update卡表（添加电子钱包id），电子钱包表（更新钱款，实体卡里面原本可能有钱哦）。

消费清单就是把每次的结算包更新到卡表，然后保存到（create）消费记录表。可以通过设备号查询该台设备所有的消费记录，where=deviceID,也可以where=cardnum,查询某张卡的消费记录，时间段可以继续添加约束条件查找，不过这种粗糙的数据结构，数据量较大时，查询速度会非常慢。

设备表，卡表，代理商表，消费表，电子钱包表，这些表结构应根据具体要求添加列项，reserved一点没错。不管怎么样，设备表，卡表，消费表，电子钱包表都应该有一个共同列项，就是代理商id。

因为客户端的识别码，就是代理商id(一般是手机号码)，通过这个id,就能操作跟这个id相关的表了。各种业务逻辑都是围绕它来的。

先有添加代理商（create 代理商表元组数据），然后才能create设备表元组数据，就是添加设备 ，添加新卡也是如此，在代理商名下添加。查看消费清单也是如此，他们都是通过代理商id绑定的。

消费清单是结算包create的，一般都是create,delete操作，达到固定时间节点，统计个结果保存，之前记录delete处理。

代理商表 设备表，卡表，电子钱包表一旦创建，大部分都是update。

客户扫码数据是如何下发到设备的说明：

这个涉及到钱，所以需要特别处理，其他的开关机，参数设置等可以通过状态包以及超时来闭合。

客户扫码获取设备状态，通过服务器下发数据到设备。客户数据如何到达设备呢，这就是之前提到的基于tcp的不同协议相互通信了，websocket,tcp,http,都可以相互通信，uid绑定各自的socket连接，查到uid就可以判断设备是否可以通信，基于订阅发布的系统更易理解。