Modernization and multi-member files

All,

As part of a modernization effort, I'm trying to move our RPG system away
from DDS-specific functions but am having difficulty finding anything in SQL
that provides the simplicity and elegance of multi-member files and RPG's
EXTMBR() keyword.

We have an application that allows users to extract a subset of order-entry
data (ORDER_HDR, ORDER_DTL, etc.) into uniquely-named members. Once cloned,
users are able to manipulate their temporary copy of the data as necessary,
running 'what-if' scenarios, etc. in their own private sandbox without
affecting the production data. When finished with a batch, the user can save
their work in the temp member, append it production, jump to another member,
etc. Since the members are in the same files they all share record formats,
indexes, RPGs, queries, *AUTLs and journals. Nice and tidy.

If this app is switched to SQL we'll have to abandon the multi-member
concept and I'm having difficulty visualizing the 'SQL way'. Partitioned
tables aren't appropriate in this case because the separation really isn't
based on a range or hash. Creating temporary libraries brings up its own set
of issues with *LIBL and security.

I suppose one could design a system with two sets of tables
(ORDER_HDR/ORDER_DTL) and (ORDER_HDR_T/OREDR_DTL_T), prefixing each row with
a key (a.k.a. "member") that each program would filter on. It seems like
extra overhead, but maybe that's because I'm looking at things from a DDS
perspective.

For future reference, perhaps some of you SQL folk would be kind enough to
offer suggestions about how you would tackle something like this.

Many thanks, JK