MES系统与数据库的“亲密关系”
系统架构
随着MES系统在生产管理方面的深入应用，系统对于生产的影响正在扩大。对于很多制造型企业来说，系统的崩溃可能直接导致生产的停滞，给企业带来较大的成本浪费。许多制造型企业对于内部的IT运维部门的考核绩效标准往往包含了一项非正常的系统宕机时间。
系统停机的原因多种多样，表现在系统架构方面的主要有以下几种情况:
1. 单一的系统应用服务器，一旦崩溃就会引起系统的不可用，只能等待应用服务器的恢复；
2. 为了节省成本，服务器上运行了多种应用，甚至数据库，导致资源的抢占而引起系统的无法正常访问；
3. 定时任务未能分类拆分，任务管理混乱，无法评估服务器的负荷是否均衡。
通过以往应用的经验积累，目前较大的系统整合服务商的产品系统架构均有如下特点：
1. 用户应用层：集合了大量与用户相关的人机交互界面，包括由C/S和B/S构成，布置在办公室电脑或现场一体机的程序应用界面，也包括打印机、手持终端（如扫描枪、PDA）以及现场的LED等看板或者报警灯。
2. 应用服务器集群：应用服务器使用集群的方式，均衡负载并且可以防止由于一台应用服务器的宕机导致整个生产系统崩溃，目前使用单一应用服务器的方式已经不能满足企业的生产服务要求，这种集群应用的模式也是界定产品应用级别的一个基本指标。
3. 其他服务器：除了将应用服务器进行集群设置，有些任务无需操作人员人机交互，无操作界面的定时任务，可以单独以服务的情况存在，这些服务与应用服务器分开，互不影响。例如打印任务的执行，系统将打印任务插入到打印队列表中，在该服务器上执行的定时任务抓取表中的打印信息发送到打印机进行打印。再如，从ERP的工单导入，也可使用该方法定时后台执行工单从ERP接口导入。这些服务的特点是：处理逻辑固定；任务定时处理；无需人工干预。
数据库架构
1 生产数据库集群
数据库的集群冗余互备一般在数据库级别的讨论范畴，不在MES产品讨论的范畴之内。在MES系统设计链接数据库方式上，链接单一数据库和链接集群数据库的方式会有一定的差别，在不影响正常链接的情况下默认支持集群数据库的链接方式。
举例：客户A已经使用MES+Oracle的单一数据库应用模式，在数据库经常宕机的情况下（原因不明）计划扩展为数据库集群，原先的MES链接数据库的方式为SID链接，SID无法支持链接集群数据库的能力，当数据库集群制作完毕后发现MES的应用无法链接到集群数据库，需要更改链接方式为Service Name的链接方式，其两种链接方式对于MES应用来说并无特别影响。如果原先就使用Service Name链接方式的话就可避免该状况的出现。
2 磁盘阵列海量数据存储
磁盘阵列一般在存储级别的讨论范畴，有专业的硬件供应商和实施服务商，不在MES产品讨论的范畴之内。在客户拥有海量数据或数据量增长速率过快，在可预见的未来，数据容量的存储会达到极限，磁盘阵列的方案可以支持存储容量的无限扩容。
3 生产数据库与历史数据库分离
在企业系统运行的过程中，数据量（一般是生产过程中的动态数据）的不断增长，差异备份、完全备份等无法减轻数据表的存储压力，当数据库表的行数达到一定的级别，对于数据库表的操作性能就会明显下降，虽然通过优化脚本和减少访问的方式进行性能优化，但面对上亿甚至上百亿的表行数，任何的优化措施都显得无能为力。数据迁移就成为了必然的选择，将一年前或者是已经完成的工单过程信息迁移到历史数据库，减轻生产数据库的压力，使生产数据库满足生产节拍的要求。
如何选择需要分离表？
数据库中的表基本分为两类，一种是静态数据表，一种是动态数据表，静态数据表是各类系统的定义，比如单位、标准设置以及业务相关的主数据，这类数据基本上不会有频繁的更新和插入，数据增长量可以忽略不计，并且数据的迁移会对原有系统的业务造成影响，所以此类静态数据表的数据不作分离。动态数据表是诸如工单、工单工序、过站记录、以及工单产品相关的质量数据等，该类数据的特点是由于新的工单不停的进入系统，在生产过程中不断的有该工单的过程处理数据，这类数据会随着工单的增长不断的增长，涉及到此类的动态数据表则需要数据分离。
综上，工单及工单相关的表数据均需要分离。
如何分离表的数据？
分离表的频率和周期依据数据增长量以及对表的操作效率进行定义，作出合适的时机选择，为了不影响生产数据库的运行效能，一般选择在非生产周期内进行。
分离的方式可通过执行后台的脚本或者使用配置界面进行数据迁移，有配置界面的好处是便于分析以及预览数据分离的细节情况。
数据分离的方式可采用先转移，转移成功后将数据迁移至中间表继续保存，待一段时间后未发现数据问题则中间表数据定期清理。依据工单转移时，工单的相关数据应同时全部转移。
利用历史数据库
历史数据库的数据庞大而完整，可依据其数据长期累积且完整的特点作报表的统计及展示，也可作为企业生产经营商业大数据分析的原始数据。在历史数据库上的报表查询和计算所带来的资源和性能消耗完全不会影响到正在运行的生产数据库的应用。
表名的命名规则
数据库表的命名规则基于可识别、易区分、可归类的原则，适当增加前缀和后缀。
以下举例：XX模块相关的工单工序表
XX_OrderRoute
XX:模块名
_:下划线分割
OrderRoute：表名，首字母大写，单数，易理解
XX_OrderRoute_AA
XX:模块名
_:下划线分割
OrderRoute：表名，首字母大写，单数，易理解
_:下划线分割
AA:附属表或属性扩展表
C_XX_Customized
C:客制化表标记
XX:模块名
_:下划线分割
Customized：表名，首字母大写，单数，易理解
支持集团化多分厂业务
跨国公司多个工厂的数据在集团层面进行合并分析，支持全球化的商业数据分析，如何在数据库及表的设计方面就能支持不同工厂的业务数据整合是系统应该考虑的问题，我们的目标是集团的数据库表结构与各工厂的数据库表结构一致，以支持未来数据的归集。
采用在业务数据表中设置字段SITE来进行各分工厂的数据区分:
1. 每个SITE即一个工厂的应用实例，所有数据库的操作业务均需要增加SITE字段的条件处理，例如查询、更新、删除、插入等操作
2. 集团数据库中可存储多SITE数据，合并所有SITE的相关数据供企业商业分析，为决策提供基础信息
3. SITE成为全局变量供所有与数据库相关操作处理的必要条件之一；
PS:该种数据库架构的模式虽然支持一个集团部署一套应用服务器，各分SITE无需部署应用服务器，通过分配不同的SITE连入到一个应用中，产生的数据也在一个集团数据库中，但由于基础架构等诸多限制，在用户响应节拍和体验性上表现不令人满意，所以尽量避免使用该类架构模式。
4. 支持主流数据库Oracle和SQLServer的较新版本，很少有产品仅支持一种数据库的应用，支持不同的数据库，使产品应用的环境更加广阔，而不至于出现需要客户重新采购数据库从而增加投入成本和运营成本的尴尬局面。
