> > understatement. If you have any significant amount of data
> > within your database, any one of these queries will be a lot
> > of work for your database server, as it'll involve a table
> > scan. If you really want to do these sorts of searches and
> > categorizations, use a full-text indexing engine like Verity.
>
> If you have a million records in your database, this would be
> stupid slow. Not every application has a million records in the
> database. I just did a test on MS Access searching 10,000 rows
> with multiple LIKEs in the where clause. Each query took an
> average of 47ms. Doing 7 unique LIKE queries (every permutation
> of 3 words, took 329ms) Granted, it did make the processor
> spike.... up to a full 2%. So yes, I concede, it is a little
> processor intensive. ;-)
I guess I should've been a little clearer in my previous post. My concern
isn't really with CPU resources, specifically, but rather that this approach
will be very problematic with any significant amount of data. Those LIKE
operators you were using require a full table scan for each one, and this
will have a detrimental effect on concurrent requests.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
phone: 202-797-5496
fax: 202-797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
