【唠叨两句】简单说一说一个最长用的数据表SysUser【系统用户表】

我相信几乎每一个用到用户登录的系统中都要有这样一个系统用户表吧,当然表的名字可能有所不同,但其代表的意义应该算是都一样的吧。

在我看来这个表是比较特殊的,我说它特殊有如下这么几项原因:
(1)一般情况下:SysUser表的主键对于用户而言是可见的,并且是系统用户自己任意添加的(在这里排除数据表对与该数据列的约束)。
而其他类型的表呢?主键一般是没有必要让用户看到的,而且其主键值一般是不受 人为操控的。 还有一点主键列通常使用的有: 启用递增的标识列,DateTime.Now.Ticks,Guid等等。

(2)在系统中,用户名就相当于代表了现实生活中一个真实的用户的身份,尤其是在一些管理系统、商务系统等等中,系统用户的每一个操作都是承担着相应的责任的,所以SysUser表中的记录是不可以随意删除的,否则当系统出现问题时,追查数据、及相关责任人时 都会遇到困难的。

基于以上的所述原因,让我们在看一个小例子,现比如有如下一个SysUser表,该表要被多个机构所共用:

UserID:                主键 char(20)用户名
UserName:                   char(20)用户真实姓名
OrganizationID:             char(30)所属机构ID号,该ID号为DateTime.Now.Ticks.ToString();
UserPhone:                  char(20)用户电话
PassWord:                  char(20)用户密码
IsUsed:                    bit      是否可用,删除的时候其实是将该字段设为 False


由于这里的主键只有UserID这一列,删除记录并不是使用的DELETE 语句,而只是将IsUsed字段改成了False,所以在这样的表结构下就回产生一个问题就是:删除一个用户名之后、再添加一个相同的用户名就会报主键约束。而且两个不同的机构之间也不能有相同的用户名。

面对这个很现实的问题,这样的软件交不了工,还得改。唉,也只能怪当时没能把这些问题考虑到。

由于这个软件的相当多的一部分编码工作已经做完了,所以要是在这种情况下去更改数据库结构,哇塞,那简直就是将一颗大树连根把起,这样做很不现实,所以要想办法降低软件的改动量。

刚遇到这个问题时、我的思考过程是如下的:
(1)将UserID,OrganizationID,IsUsed三列弄成一个主键列,但是这样做也是有问题的,比如这种情况:已经有一个UserID 为 “AAA”OrganizationID 为 “18个8”的用户被删除,现在有添加了一个UserID为“AAA”OrganizationID 为 “18个8”的用户,但是这个用户一旦被删除就会违反主键约束。

(2)增加一个ID列作为主键,但是这样还是有问题的,因为这样做UserID就不能作为其他表的外键使用了。

(3)将UserID和OrganizationID设成主键列。删除时 使用DELETE 删除数据,但是同时要用另外的一张表来保存UserID 的历史记录,即某一个UserID对应的真实姓名、创建时间、每一次的修改时间、删除时间,注意这张表中数据只允许添加不允许修改和删除。但是这样做还是于上述的(3)无任何差别,同样改变了主键列,导致外键失效。

(4)经过上面的思考已经能够明确,SysUser这个表的主键列不能改动,但是还要解决上述的两个问题:【删除一个用户名之后、再添加一个相同的用户名就会报主键约束。而且两个不同的机构之间也不能有相同的用户名。】
慢慢想来,其实这些问题可以转化为如何实现“用户所见【用户名】和数据库实际保存【用户名】相分离”,再具体一点就是【在此以UserID 为 AAA  机构编号为 “18个8”为例】:
    如何将AAA经过一个特定规则转化成其他数据然后保存到数据库中,
再深度思考一下我们可以这样做:将UserID长度改成60,保存数据时UserID列实际保存的数据是
“UserID【长度不固定、但是可以计算出来】”+“OrganizationID【18位、长度固定】”+“一个顺序的四位编号【4位、长度固定】”,读取数据时UserID还是读取用户所见的真是UserID。
其中的“四位顺序编号”是用回来解决相同机构中相同UserID的问题,即同一个机构中第一次出现的“AAA”,默认给他分配“0001”,同一个机构第二次的“AAA”给他分配“0002”,依次类推。【四位的顺序编号、分配最好还要借助一个表去完成,这个表的机构是UserID【用户所见用户名、主键】,OrganizationID【机构编号、主键】,Index【四位顺序编号】】

这样以来就做到了“用户所见和数据库保存相分离”,这样做只需要改动“相关的UserID列的读写即可”,改动算是比较小的,可以解决上述问题。

嘿嘿…… 大侠们见效喽,如果您还有更好的想法和建议,还望多多指教哦…


 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 使用OneNET云平台提供的API可以实现用于接收NB-IoT反馈信息的微信小程序的代码设计。首先,要利用OneNET的API来设置NB-IoT设备的相关参数,确保它能正常工作。其次,利用OneNET的API建立一个与NB-IoT设备的连接,以便可以接收其发送的信息。最后,利用微信小程序开发工具编写代码,实现接收NB-IoT反馈信息的功能。 ### 回答2: 要使用OneNET云平台提供的API来实现微信小程序的代码,帮助实现接收NB-IoT反馈信息的过程,可以按照以下步骤进行: 1. 首先,在OneNET平台上创建一个设备,并获取该设备的设备ID和API Key。 2. 在微信小程序的代码中,引入OneNET平台提供的API库,并初始化API库。 3. 在小程序代码中编写一个用于接收NB-IoT反馈信息的函数。可以使用微信小程序提供的WebSocket API来建立与OneNET平台的连接。 4. 在该函数中,使用OneNET平台提供的API中的设备数据推送接口,将接收到的NB-IoT反馈信息传递给OneNET平台。 5. 将该函数与微信小程序的相关事件进行绑定,如启动程序时自动执行、点击某个按钮时执行等。 6. 在小程序界面上,可以显示接收到的NB-IoT反馈信息,以及其他相关信息。 需要注意的是,以上步骤仅为一个大致的实现流程,具体的代码编写需要根据实际需求进行调整和完善。此外,还需要合理调用OneNET平台提供的API,确保设备信息的传输安全和正确性。 ### 回答3: 要实现接收NB-IoT反馈信息的过程,可以借助OneNET云平台提供的API来实现。首先,在微信小程序中需要调用OneNET云平台的API来获取NB-IoT设备的反馈信息。 首先,在微信小程序的代码中,需要使用微信小程序的请求API来发送HTTP请求给OneNET云平台。请求的URL应该是OneNET云平台提供的API接口,具体可以参考OneNET的API文档。 在请求中,需要提供OneNET云平台的设备Key以及需要获取反馈信息的设备的ID信息。同时在请求头中,还需要设置正确的Content-Type来指定传输的数据是JSON格式。 请求发送后,OneNET云平台会根据设备ID和设备Key来验证请求的合法性,并将相应反馈信息作为JSON格式返回。 在微信小程序中,可以通过注册相应的回调函数来处理OneNET云平台返回的反馈信息。在回调函数中,可以解析返回的JSON格式数据,并根据需要进行相应的处理操作,例如展示反馈信息或者进行其他逻辑操作。 此外,为了保证数据的安全性,可以在发送请求时使用HTTPS协议来进行数据传输,以防止数据被篡改或者泄露。 总之,通过使用OneNET云平台提供的API来实现微信小程序的代码,可以方便地获取NB-IoT设备的反馈信息,并根据需要进行相应的处理操作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值