|
As far as the optimizer goes, you can still turn on RDMS$DEBUG_FLAGS and
truly see that yes, when the request goes against the database, it will
make use of indexes provided your request tries to - for example:
if PART_ID is indexed in your database and in your FOCUS request you say
IF PART_ID EQ ...
It will attempt to use the index - on the other hand if you do
DEFINE FILE ...
TEMP/A2 = EDIT(PART_ID,'99$$$$$$$');
END
TABLE FILE ...
IF TEMP EQ ZZ
Since you are doing a selection on a defined field, it probably won't
make use of an index on PART_ID - in this case you might as well say
IF PART_ID EQ 'ZZ$*' in your FOCUS code - that way you probably will get
the index.
Give me a call.
LisaC
|
|
You can either keep them one per table or combine them as you need to.
For example:
If you had orders with a lot of line items per order,
you might want to create a master and .acx file which
maintains the relationship of the order with the line items
for you so that you can just go after the one master and
get information from the two tables at one time.
Or, you would have to join the tables via a FOCUS command -
whichever your end-users/you prefer.
TABLE FILE ORDERS or
JOIN ORDER_NO IN ORDLINES TO ORDER_NO IN ORDHDR
TABLE FILE ORDLINES...
Don't know if I would make one for the whole entire database.
If you do, then chances are that you could be trying to make relation-
ships between data that really need to be accomplished another way.
There's a good chance you could get the warning message 'TESTING OF
INDEPENDENT SETS OF DATA'...also, by making one for the whole database,
you will only get ties to data that actually make it through the
entire join path of the data - the use of MATCHES can deal with those
type of relationships where something is in A and not in B but
you still want your result to include what info there is in A and
print out missing values for B - with the master for the entire
database, you will miss this.
LisaC
|