John,
If all the data must be synched simultaneously then I don't see any performance benefit of using sub-tables and requerying more views. Basically, the same amount of data is being returned by 12 views as opposed to 1 view.

However, if you can spread that information over several UI interfaces (e.g. pages on pageframes) and requery the appropriate views when needed (like delayed instantiation), it will probably help performance all the way around.

>Hi Folks,
>
>I have an application that's a secure document management system. Each document is composed of contract clauses, each of which is stored in a General field. Each client can have multiple documents.
>
>This application evolved over time and the document child table now has about a dozen General fields. The document table is represented in the main application screen by a view (for simplicity, I'll call it lvdocuments). Lvdocuments is optimistic table buffered and in the application it's requeried if the user clicks on a list of documents for the current client and when the client is changed. The client table is a table and is optimistic row buffered.
>
>The client is concerned about the speed of the application. It's a bit more sluggish as time goes on. I have been considering moving each document clause (read: General field) into a grandchild table, but my main question is this:
>
>Will the general application speed increase or decrease by remiving all of the General fields from the documents table and putting them in child tables? Each table is much more lightweight, but then I have a dozen more views to requery...and then there's the issue of updating and reverting if the user changes the current document while editing.....
>
>This is the only application I maintain that uses a slew of General fields and I'm thinking the answer is not so obvious....
>
>Opinions and ideas are welcome!