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
