Carey, Scott, Axton & Rick, Thanks for the ideas. I will give the GUID a try but I also have to account for the migration of data that is not in the exact same table structure as I am creating here. I plan to make my import files with Request_IDs for keys and then I can enable and distribute the GUIDs. The reason for the change to using GUID is that I was informed by the user that "all of the steps (child/grandchild records) can be entered at one time". With GUID available before the Submit, as you all have noted, this is handled easily. So now I get to learn the practical application of the GUID.
Thanks for all the help, 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 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Sunday, October 22, 2006 1:22 PM To: [email protected] Subject: Re: OT: DB design multiple joins Scott, I can see one reason to use 'Request ID' instead of a GUID. The 'Request ID' column is the clustered index column for an ARS table. Performance on that index will always out perform any other index that you might add to the GUID field. However, all of the other reason to use a GUID (IMHO) out ways the "cost" difference between the clustered index and an ordinary index. If you find yourself developing in the special case that the parent record is _always_ created before the children, then you likely should use the 'Request ID' value as the glue. But if there is a potential that the creation even of the parent would actually also create one or more children too, then you likely need to use GUID's. (Even if they are only temporary keys to cross map the parent 'Request ID' after it is known.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 10/21/06, Scott Parrish <[EMAIL PROTECTED]> wrote: > John, > In general, I can't think of a single reason to utilize the request ID > over a GUID to create and maintain parent/child relationships. I > think, overall, it is a much cleaner way of establishing > relationships. You can utilize a set fields $PROCESS$ to generate a > GUID at any time so this is especially valuable if you are using > Display Only forms for data entry and creating one-to-many or many-to-many relationships. > > For instance, Remedy's Customer Service and Support application > utilizes the concept of an OperationID. If you were utilizing a > display only form to create your MR and at the same time it's > associated POs and Line Items, then suddenly decided that you wanted > to complete None of this, you could reference the Operation ID to > delete the MR and all of it's relationships using a single field of > reference. You would just generate the Operation ID using a GUID when > the initial Display Only form were opened, then push it to create all relationships. > > There are many, many other reasons for utilizing the GUID over the > Request_ID field and I'm sure others on this list can give you > different examples. I think once you start using the GUID in your > workflow you'll see how easy and powerful it can be. > > Remember that a GUID is ALWAYS unique. If you were combining two > Remedy systems into one, such as HD, if you utilized GUIDs to maintain > relationships you would never have to worry about how duplicate > Request IDs might affect your relationships. > > Scott Parrish > IT Prophets, LLC > (770) 653-5203 > http://www.itprophets.com > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Reiser, John J > Sent: Saturday, October 21, 2006 11:42 AM > To: [email protected] > Subject: Re: OT: DB design multiple joins > > Axton, > > I will probably use joins in some fashion, maybe for a report form. > At the top level I think it will be the main form with tables and DO > fields to display data, with Open Window actions to create/modify children records. > > I wasn't planning on using the GUID, instead I was just going to use > the Request_ID of the parent. Child records are created from modify screens. > Aside from the lack of a Request ID at the create time of the parent > are ther other benefits to the GUID? Or where you using the general term guid? > > > Thanks for the reminder about indexing. > > 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 > > ______________________________________________________________________ > ______ > ___ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at > http://www.wwrug.org > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
