No, for the apps I write where I use a relational model, I find the guid convenient. It's available when I need it (no waiting until after record creation) and it's always present. It makes looking at the data with your eyes hard, but the db is indifferent. One just has to get used to using the proper tools to interpret the data instead of opening forms to look at the data. The request id would probably be more effecient from a database perspective due to the fact that it has less data. The main argument I have against the request id is that I can not create child records before creating the parent record. This can introduce issues with the user interface/experience that I would prefer to avoid altogether.
Axton Grams On 10/21/06, Reiser, John J <[EMAIL PROTECTED]> wrote:
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
