home bbs files messages ]

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