>From: David Wolverton >Would we be better off to create a "Virtual" field definition to index that carries the 'real' code into the index, unless it is COMPLETE, in which case we would make the virtual field pass a NULL and then index this new virtual field using NoNulls?
Assuming COMPLETE can't be changed to null in the app, yes. One consideration you haven't discussed is the amount of impact on the existing app, and this strategy would minimize that impact. I wouldn't go writing a subroutine to do the calculation, but with a simple IF the overhead should be minimal. >But it does not appear to me that the 'size' of the index created has significant operational cost ... The size of the index - that is, number of records indexed - does in fact have an operational cost. Minimize the size of the index - particularly if a large percent of the records don't have to be in there, and performance will positively reflect it. If you're only dropping a small percentage of the records from the index with NO.NULLS you might not notice a difference, but drop a large percentage and I bet you'd notice the difference. > possibly not as much the expense of doing all those Virtual Field computations along the way If it's a subroutine, then I would expect the computations to have some expense. A simple IF should have minimal impact. >Plus, if we ever DO need it, COMPLETE is indexed for selection. If COMPLETE is needed, you might consider a separate indexed field that uses COMPLETE with some other criteria that may be useful for reporting. At least then you're starting a new index tree independent from the other one. Not sure if this qualifies as "best practice", but that would be the direction I would lean. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com ** Check out scheduled Connect! training courses at http://www.PrecisOnline.com/train.html. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
