[progress Communities] [progress Openedge Abl] Forum Post: Re: Overhead Of Multiple Unique...

Status
Not open for further replies.
G

guymills

Guest
Hi Richard Just a question: If your pattern is generally: Index-A, ssn Index-B name, ssn index-C cardID, ssn etc... Is ssn just an internal key, which has no data relevance? Or is it a field that the users want to see, and (sub-)order their results by? I ask, because if it is just an internal ID, then what is the need to include this field in the other indexes? i.e. why do you want these indexes to be unique? There are implications of doing so: I'm not an expert (like Gus - who I believe designed the bulk of the OpenEdge DB engine), or George is. But from what I understand, the index keys are a concatenation of the index fields, and also the index keys will be compressed. So e.g. if you have 2 indexes: idx1 (name) and idx2 (name, ssn) And you have e.g. 4 records: name ssn recid (Progress internal pointer to record) fred 100000001 1 fred 100000002 2 bob 100000003 3 bob 100000004 4 idx1 will be compressed to something like: fred 1,2 bob 3,4 whereas idx2 can have no compression (because of your use of the unique key as the final entry of the index): fred100000001 1 fred100000002 2 bob100000003 3 bob100000004 4 [I know it's not really like this, but just to give the general idea...] I guess if you're not dealing with much data, then this isn't a problem, but if you're dealing with million of rows, you may free a considerable amount of space by not including the unique key in the index, and potentially (this is for others to say...) it might perform better... Cheers, Guy

Continue reading...
 
Status
Not open for further replies.
Top