Platform Issues 平台问题

Set processing does not behave the same on every database platform. On some platforms, set processing can encounter performance breakdowns. Some platforms do not optimize update statements that include subqueries.

集处理在每个数据库平台上的行为并不相同。在某些平台上，set处理可能会遇到性能故障。有些平台不优化包含子查询的更新语句。

For example, environments that are accustomed to updates with subqueries get all the qualifying department IDs from the Department table and then, using an index designed by an application developer, update the Personnel table. Other platforms read through every employee row in the Personnel table and query the Department table for each row.

例如，习惯于使用子查询进行更新的环境从Department表中获取所有符合条件的部门ID，然后使用应用程序开发人员设计的索引更新Personnel表。其他平台读取Personnel表中的每一个employee行，并查询Department表中的每一行。

On platforms where these types of updates are a problem, try adding some selectivity to the outer query.

In the following example, examine the SQL in the Before section and then notice how it is modified in the After section to run smoothly on all platforms. You can use this approach to work around platforms that have difficulty with updates that include subqueries.

在这些类型的更新是一个问题的平台上，请尝试为外部查询添加一些选择性。在下面的示例中，检查“之前”部分中的SQL，然后注意如何在“之后”部分修改它以在所有平台上顺利运行。您可以使用这种方法来解决那些在更新包含子查询时遇到困难的平台。

Note: In general, set processing capabilities vary by database platform. The performance characteristics of each database platform differ with more complex SQL and set processing constructs. Some database platforms allow additional set processing constructs that enable you to process even more data in a setbased manner. If performance needs improvement, you must tailor or tune the SQL for your environment. You should be familiar with the capabilities and limitations of your database platform and be able to recognize, through tracing and performance results, the types of modifications you need to incorporate with the basic set processing constructs described.

附注：一般来说，集合处理能力因数据库平台而异。每个数据库平台的性能特征因更复杂的SQL和集合处理构造而不同。一些数据库平台允许附加的集合处理构造，使您能够以基于集合的方式处理更多的数据。如果需要改进性能，则必须为环境定制或调优SQL。您应该熟悉您的数据库平台的功能和限制，并且能够通过跟踪和性能结果来识别您需要与所描述的基本集合处理构造合并的修改类型。

Basic version:

基本版本：

UPDATE PS_REQ_LINE

SET SOURCE_STATUS = 'I'

WHERE

EXISTS

(SELECT 'X' FROM PS_PO_ITM_STG STG

WHERE

STG.PROCESS_INSTANCE =%BIND(PROCESS_INSTANCE)  AND

STG.PROCESS_INSTANCE =PS_REQ_LINE.PROCESS_INSTANCE AND

STG.STAGE_STATUS = 'I'  AND

STG.BUSINESS_UNIT = PS_REQ_LINE.BUSINESS_UNIT AND

STG.REQ_ID = PS_REQ_LINE.REQ_ID AND

STG.REQ_LINE_NBR = PS_REQ_LINE.LINE_NBR)

               •     Optimized for platform compatibility:

针对平台兼容性进行了优化：

UPDATE PS_REQ_LINE

SET SOURCE_STATUS = 'I'

WHERE

PROCESS_INSTANCE = %BIND(PROCESS_INSTANCE) AND

 EXISTS

(SELECT 'X' FROM PS_PO_ITM_STG STG

WHERE

STG.PROCESS_INSTANCE =%BIND(PROCESS_INSTANCE)  AND

STG.PROCESS_INSTANCE =PS_REQ_LINE.PROCESS_INSTANCE AND

STG.STAGE_STATUS = 'I'  AND

STG.BUSINESS_UNIT = PS_REQ_LINE.BUSINESS_UNIT AND

STG.REQ_ID = PS_REQ_LINE.REQ_ID AND

STG.REQ_LINE_NBR = PS_REQ_LINE.LINE_NBR)

Note: This example assumes that the transaction table (PS_REQ_LINE) has a PROCESS_INSTANCE column to lock rows that are in process. This is another example of designing your database with batch performance and set processing in mind.

附注：本例假设事务表（PS_REQ_LINE）有一个PROCESS_INSTANCE列来锁定正在处理的行。这是在设计数据库时考虑到批处理性能和设置处理的另一个示例。

This modification enables the system to limit its scan through PS_REQ_LINE to only those rows that the program is currently processing. At the same time, it enables a more set-friendly environment to first scan the smaller staging table and then update the larger outer table.

这个修改使系统能够通过PS_REQ_LINE将其扫描限制为仅扫描程序当前正在处理的那些行。同时，它支持一个设置更友好的环境，首先扫描较小的分段表，然后更新较大的外部表。