在MES 系统中，数据库是一个很重要的元素，但这已经不是选哪一个数据库的问题了，这里还需要考虑 MES 系统的整体架构设计以及数据库是如何搭建的。yh1122银河国际在开始设计 MES 的时候，不仅要考虑支持不同的数据库（不同的客户，不同的行业，可以有更多适合的选择），同时更重要的是满足国内信创的要求。

在半导体/精密制造行业，已经不是单纯的使用简单的数据库架构（例如一主一备）可以解决的问题，否则硬件就是天花板了。

记得 15+ 年前，我们用在 12 寸晶圆厂的 MES 数据库的硬件是 32 颗 CPU （一颗 4 核），256G 的内存，这已经是天价的硬件规格了，记得当时跑得不太流畅的时候，惠普的顾问和应用材料讨论以后，建议我们把 CPU 加到 64 颗，内存升至 512G，我们当时就震惊了，要知道当年笔记本的上限是 8G。

当然后期的数据库设计，加入了很多的元素，例如 Online/ODS/DWH 的三层资料库设计，这些设计也带来了很多的问题，例如资料库之间的同步机制，数据的可靠性等，这就考验了 MES 厂商的水准和素质。

目前大部分的主流的关系型数据库（不论是开源的或是商业的），基本上都可以满足做为 MES 数据库的使用。

半导体生产/精密加工行业的 MES 系统基本上使用的数据库不外乎 Oracle /SQLServer /DB2，说实话愿意使用 MySQL、PostGresSQL 等开源数据库的客户其实很少，原因很简单，没有人愿意为了数据库授权费用冒险，管理层才不会为了小几十万的数据库授权费用，冒险让几十亿投资的工厂停止生产。

我在上家欧洲的MES公司的时候，当时的策略是明确的==》以微软做为单一的技术栈，所以自然而然的，使用 SQLServer 成为了唯一的选择。在那个 SQLServer 被黑的时代（早期的 SQLServer，数据超过 XX 万笔以后，性能会断崖式的下降），对于销售是很不容易的。我们每一次都要费一番口舌来说服客户，为什么 SQLServer 比 Oracle 好用，当然也因为这样，有几次我们连去投标的资格都没有。

说实话，当时其中一个卖点是便宜，在SQLServer 还可以用 Cal （连接数量）购买的年代，人民币五位数就有可能买到可以用的版本了，但是这个优势在 2014 以后就没有了（微软和甲骨文看齐，用 Core 数来卖了）。当年我们和研发沟通过很多次，为什么不能够兼容 Oracle 呢 ？我们不是用 ORM 吗，移植不应该是难事。但研发总是用一堆理由来说明这是不可能的，我们一直都觉得这是研发不想做事的理由，但我们无法影响研发。

当然我们必须要说，SQLServer 在过去的十年真的有了很大的进展。特别是后期推出的 AlwaysOn 技术，让客户不再需要购买额外的储存硬件，就可以实现硬件的主备，和 Oracle RAC 收费相比，还真的是良心厂商。SQLReport Builder 和 PowerBI 都是加分项。但和微软的 Active Directory 权限绑定比较麻烦，无数次因为 AD 权限设定的问题，都花了很长的时间才能把系统装起来，特别是客户有自己的 AD 系统，AD 系统之间的权限同步问题实在不是一件容易的事。到最后，为了提供客户更好的服务，我们都会安排欧洲总部的专家来进行安装，因为实在是太费心力了。

来到yh1122银河国际以后，yh1122银河国际的 MES 生产运营系统设计在一开始就锁定要支持不同的数据库系统 （不想要再来一次单一技术栈的路）。

我们面对的第一个问题就是要选择哪一个数据库呢 ？

最直接的选择就是数据库排行榜的开源第一名 ==》 MySQL, 这是一个进可攻退可守的选择，一方面适合拥抱开源的客户，另一方面是愿意花钱的客户则依然买的到专业的维保服务，同时资源众多，客户也很容易在市场上找到懂数据库的开发和维护人员。

在yh1122银河国际的MES生产运营系统进入 3.0 版本的时候，我们又重启支持多数据库的研发。

这个时候，我们考虑的事情也变得更多了，由于贸易战的关系，国产替代和信创更是重要的考虑因素之一。

从国产的数据库龙头中（TiDB，openGauss, PolarDB，OceanBase), 我们最终选择的是 openGauss, 最主要的原因是华为在打造的是一个生态，而不是只有数据库。还有一个最重要的点是，华为推荐了我们基于 openGauss 的数据库厂商 （海量），和海量团队讨论过后，他们打造的完善的管理和运维工具也是我们做决定的重要因素之一，这点保障了我们的客户有个能依靠的厂商。同时，国产数据库都是有一定特色的，例如 OceanBase/PolarDB 更是主打运营商的能力（租户管理等），也有缺点（例如 TiDB 不支持存储过程和外键），这些都是我们考量的点。

虽然yh1122银河国际的MES生产运营系统设计是基于ORM的模式，但是数据库移植也不是那么直接的，换个驱动就可以了。我们其实采取了两步走，第一步先移植至 PostGresSQL，然后再移植至 openGauss/海量，这是一石二鸟的规划。一方面满足国内信创要求，另一方面也兼顾了国外的需求（我们支持两大开源数据库！）

其中的细节还是满满的，我们花了一个月左右的时间，完成了整个系统的移植。