Nested Table columns and ADF BC 11.1.2

Question

I'm thinking ahead to a new application design, including a new database design. In this application, there are users who may not change the production tables directly, but their changes must be approved (and possibly modified) before they are applied to the production tables. The production tables are part of an existing system, and are fairly well normalized, with a master table and several detail tables.
So for the new design, I want to have a staging table, mirroring the master table, where user changes are stored until they are approved and applied to the production tables. The staging table contains a few extra columns for "add, change or delete", user who submitted the change, date the change was requested. After applying the change, the staging record is to be copied to a change history table, and deleted from staging. That way, the staging table never has a lot of data in it.
Here's the question:
I need to deal with the detail tables. I could have staging versions of each detail table, but I was thinking that it might be easier to handle if the detail tables were included as nested table columns of the master staging table. Most of the detail tables only contain a few rows per master row. But can ADF BC 11.1.2 handle nested table columns? Is it easy to use in an application?

Answer 1

Thanks for the quick response. I was thinking I might get a response from someone who had tried it, so I didn't waste time trying it myself. I consider your response is pretty authoritative, and I'll take that as a sign that I should forget the nested tables design.
No, polymorphic views probably won't do the job. I think I'll just go ahead and create staging versions of each detail table with foreign keys back to the master staging table. Then I'll let the wizard create the needed association objects and view links in ADF BC. It will complicate the procedure for applying changes, particularly adding a row to the change history table. But that's the price we'll need to pay.
OTOH - I just had a thought - since the change history table is mostly for auditing, it appears in some reports, but has no CRUD in the application, other than the insert when the changes are applied. If I did that insert with a trigger or some other PL/SQL, then the change history could still be a single table with nested table columns for the details.