Rick,
I started to think of using the joins for the "Main Form"
so the user could see all of the fields that they edit. I didn't like the idea
of multiple entries returned on a high level (parent) search so I headed in the
Table and DO filed direction.
The one thing that I liked about a join was the fact that
updating data on the join form is actually updating the base form data. No
workflow to maintain. I'm sure I will use a join here or there in the
application but I will stick with the Tables and DO Fields for most of
it.
Thanks and have a nice weekend,
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
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Friday, October 20, 2006 11:48 AM
To: [email protected]
Subject: Re: OT: DB design multiple joins
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___
__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
