FME SQLexcutor与featurereader结合的优点

SQLexcutor可以执行SQL语句，此转换器可以用于大量的属性处理操作（如：更新），当属性更新项非常多时，涉及很多的多表连接与查询等操作，此方法要明显快于FME进行类似的处理操作。通过FME其他转换器处理属性时，事先需要读取数据到FME才做能做其它属性处理，这势必会过多地占用客户端的CPU与内存资源。但是如果我们直接用SQLexcutor直接写SQL处理属性时是不会在客户端读取数据以及执行SQL。客户端会发送SQL语句到服务器端执行，做到尽量使用数据库的功能。通常（服务器）数据库端几乎是没有空间方面处理的功能，假如安装就是个普通关系数据库，但是它有存储坐标串的大字段，需要借助其他软件来实现，如：arcgis、fme等来实现空间处理功能。因此对于这种需要空间处理的操作，可在客户端上执行，充分利用服务器端与客户端的CPU、内存等资源。

下面通过一个本人亲测的例子来说明。Oracle数据库上存有几张关系表需要处理，主要是属性约束条件与空间拓扑的检查，如存在问题，则在对应的表中更新属性，标注错误的代码。属性约束条件主要是检查是否为空，是否重复（唯一值），外键连接关系是否满足等；而拓扑检查主要检查面（重叠、自相交）、线（自相交）、点（范围不正确，如点不在最大的面内）等。WKT通常用来存储坐标属性，是一种很常见的GIS数据文本存储格式，它在oracle中可用CLOB大字段来存储。

先用SQLexcutor执行SQL语句完成属性约束条件检查，然后与之前的SQL执行的结果联系起来（区分前后，FME转换器是阻塞式的），因为一条记录既有空间，亦有属性。空间和属性检查分开，但最后还得拼接起来，保存错误代码。如图1是部分的SQLexcutor与featurereader结合处理方式，这几张表数据量有12W+，以此方式处理，不到3分钟即完成，如图2。当然这和数据质量有关，特别是空间方面如果存在很多拓扑错误，势必会降低速度。这只是十几万的数据，比较小的数据量。之前已尝试过不采用SQLexcutor方式处理属性，因为大量的使用featuremerger与listbuilder等转换器，结果计算机卡爆，差点就动不了，时间也是很长。FMEfeaturemerger不适用于太多的表连接操作的场景，如能用（服务端）数据库的资源尽量使用，交给数据库去处理。

图1

图2