经常见到扫码，偶尔观察了一下扫码终端机，有一些猜测和想法。扫描仪终端机通过网线连接到后端服务器，扫码后的信息应该保存在后端服务器的一个关系数据库里。刚开始做华为时曾经浏览了一下扫码终端机，发现界面有些地方的数据出现只有数据库或Excel表格里面特有的字符串，更加验证了扫码的数据存在数据库的想法。曾经思考这个数据库背后的数据结构，表结构，如果让自己设计这样的一个关系数据库，应该怎样设计？感觉不是太复杂，一条流水线，两个扫码终端机，而且扫码传输的仅仅是一个个字符串，数据并发量微乎其微，用SQLite那样的微型实时数据库都感觉有点大材小用了。
#扫描过程中两台终端机和后台数据库的运行过程
建立或者切换数据表，添加表属性（时间，线别，工令，），添加数据存储规则（比如一台机基座——电源——风扇扫码先后顺序，三类条码对应的字符串长度或者格式应该不一样，这样很容易建立存储规则，扫完基座条码后数据库和扫码终端机会立刻切换到电源的扫码状态，此时扫基座和风扇条码数据库和终端机会报错，如果完成上述三类条码的扫描行为后，扫码得到的三类数据会以行的形式存储在数据库的同一行，数据库会切换到下一行，开始新一台机的存储过程，终端机也会重复上述循环扫码模式。线尾扫码情况应该会更简单一点，两台扫码终端机在线共享数据库里的同一张数据表，在扫基座条码前会扫大箱号条码，此时的基座条码信息已经存在数据库文件里了，线尾的终端机扫基座条码时会定位到数据库所在表里面对映的那一行，并把前面的大箱号条码信息添加到对应的那一行所在位置，），特殊情况下还要扫风扇和喇叭外箱的批次条码，这些条码对应的字符串信息以怎样的形式存储在数据库里？估计在正式扫码前会存储在表的属性文件里。
#串码的情况
很容易理解，切工令时按照电源-散热器-基座顺序循环的扫码顺序，后台数据库会把扫码识别出来的结果以行的方式保存在数据表里，一台机的扫码结果保存一行，第n台机扫了电源，漏扫散热器，基座条码，第n＋1台漏扫电源，数据库把原本两台机的扫码结果当成一台机保存在数据表里，后续扫码的结果全错开了。处理错误的思路也很简单，有两条思路：在表里把第n台机的电源单元格里的数据清空，然后从第n＋1行开始把后面电源对应的扫码数据整体往上移一行，原本的第n台机重新扫码。后一条思路是在数据表里把散热器，基座数据从第n台机开始整列往下移动一行，然后把第n台机的散热器，基座数据补进去。听起来很复杂，放到Excel里就很容易理解了。
#条码打印出来后其对映的条码信息也应该在扫码前录入到数据库这些文件会放在数据库里的哪个位置？
个人感觉会放在数据字典文件里，在扫码同时会频繁查询数据字典里对映的条码信息放到数据表里面，这些信息文件事先放在数据字典里最适合不过。扫码的过程就是把数据字典里不同条码对映的字符信息按照一定的规则以行的形式保存在数据文件里。
#扫描仪切工令，切电源过程中后端数据库有哪些行为？
数据库可能会切换到一张新的表。
#扫码错误情况
**没按照规定的扫码顺序扫码，数据库给终端机报错
**重复扫码，扫描识别出来的条码信息在数据表里已经存在，数据库报错。
**条码折叠污迹或者损坏，终端机无法识别条码信息
**流水线中间的扫描仪没扫到某台机基座条码，线尾扫码时在数据库里找不到对应的基座条码数据，终端机报错。其实这种报错机制也可以检查前面的扫描仪漏扫基座条码的情况。
**条码打印出来后没有将对应的条码信息录入数据库字典，扫码时无法识别。
很久以前就有一些猜测和想法，疫情期间把所有的问题以及自己的一些推测，想法综合在一起整理了一下，为此把数据库相关的书几乎翻了个遍，没想到居然弄明白了以前一直想不明白的很多问题，对数据字典，游标等概念理解更深了。
现在让自己独立设计这样的一个满足需求的数据库起码有了一些思路。以上全都是基于个人直觉和猜想，如果所有的数据都简单地保存在纯文本里那就没办法解释切工令，切电源，漏扫，扫码报错，串码的情况。
