Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.paradox    |    To crash or not to crash, asks Borland    |    9,834 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 8,858 of 9,834    |
|    Anders Jonsson to All    |
|    Re: Query directly from secondary index    |
|    18 Oct 07 17:20:39    |
      From: gt3TakeThisAway@bredband.net              > But, it will only go through all the rows of the index, not the base       > table.       > At one client, Customer.db is 650kb but Customer.XG1 is only 66kb. 10       > times       > smaller should be 10 times faster, or more since I'm not getting network       > retries.              I'm certainly no expert on this but wouldn't the file size of .db file have       a rather minor impact?              Your only search ONE column and then it must be number of records that is       most important. I assume you have exactly the same number of records in both       .db and .xg1?              But maybe the entire table needs to go over the network even if you search       only one column? I have no idea, but even then 650 kb is not much on a       modern network.                     > Right, but I didn't want to force my users to enter data a specific way -       > 'Jim Moseley' or 'Moseley, Jim' or whatever. Also, it helps them if they       > can't remember how to spell, ie. 'McGuire' 'Maguire' 'MacGuire' can all be       > found with '..guire..'.              I understand, but in there lies your problem. If you want a flexible search       you will have to offer some performance.              But how slow are your searches?              If you had split your name in to fields firstname and lastname you could       have given the user options, either "fast search" or a slower but more       flexibel one.              Sometimes when I have a situation where performance is really crucial, I       would try to "cache" the data to the users PRIV. All operations against       tables in PRIV are always faster than in any other folder, even compared to       other folders on C. I have no idea if this could be used in you case but it       might be worth a try?              Finally I would also compare a tCursor scan to a query, sometimes I have the       impression that cursors could be quicker even when no index is used.                     Anders              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca