John, this doesn't seem join-related. Parent/Child architecture, as you've laid it out, seems more sound to me with the table fields than with multi-level joins.
Rick
On 10/20/06, Reiser, John J <[EMAIL PROTECTED]> wrote:
__20060125_______________________This posting was submitted with HTML in it___
Hello Listers,
This is more of a sanity check. ( I am the only one fluent in
Remedyspeak around here)
I have a system I am building for our Purchasing team.
To track the process I am building multiple forms because:
each Material Request (MR) has zero or more Purchase Orders (PO) at
create time.
each PO has 1 or more Line Items (LI) at create time
each LI has 1 or more Shop Orders (SO) at create time
I've made a cascading layout of forms.
MR
to PO
to LI
to SO
each using the Request ID of the one above it to keep parent-child
relationships. The reasoning behind this is to help with referential
integrity. If a parameter associated with the MR changes I only want to
change it in one place and let the system display or propagate the
changes. Sort of a Relational DB structure.
What I am confused by is the use of Multi-level joins for such a
structure. Is it detrimental to performance? Is it worth it to build all
of the "on Submit" workflow needed for Joins? I'll have to pop up lots
of windows without the join so I have issues there as well.
I was going to use Table fields and Display Only (zTmp...) fields to
show as much data as I can on one form.
This way I don't return 15 records for one MR entry in the results list.
Then I saw the reference to Occam's Razor on the link Stephen led us to
on CodingHorror and I thought, "Don't over complicate things."
Am I way off base here or is my theory sound enough to continue?
Thanks,
ARS 6.3 Patch 003
Midtier 6.3 Patch 14
MS SQL 2000 SP2 on a remote SAN
John J. Reiser
Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased
by me
