Re: [PHP-DB] Building indexes

listread wrote:
> Chris,
> 
> I just assumed that everyone on this list was using MySQL...  That's 
> what we're using (v. 5.1.45 GA) with InnoDB as the engine.

Most people are but there are lots of types of databases out there :)

> (I just read your tutorial at http://www.designmagick.com/article/16/  
> It was very helpful - I look forward to checking out more of your 
> articles.)
> 
> If it is just as efficient to use multiple separate indexes, that would 
> make index building less complicated on our large db.

It is, though wildcard searches can't always use indexes.

If you do

field like 'abcdef%';

then an index can potentially be used because the db (mysql or 
otherwise) can look at the start of the string to see if it matches. The 
longer the string the more likely an index can be used (eg doing field 
like 'a%' probably won't use an index, it'll end up being quicker to 
scan the actual data).

If you do

field like '%abcdef%';

then an index can't be used since abcdef could appear anywhere in the 
string.

> Without a large dataset, it hard to truly test a system and if you have 
> a large dataset, like we do, it takes quite a while to build indexes.

Definitely, it's the best way to test and also the hardest since 
rebuilding the db takes so long.

> Our project is a petition signature validation suite.  Since many of the 
> handwritten names and addresses on petition sheets are difficult to 
> read, the user needs to be able to do some fuzzy searching.   Sometimes 
> it's easier to read the address than it is the name.   The zip code is 
> usually easy to read.  We almost always need to use LIKE queries, since 
> some part of the name or address is typically hard to read.  (We try to 
> use as many of the leading characters as we can and wildcard the 
> remaining.)

I'd suggest fulltext but that won't work with innodb, only myisam. You 
could do something like keep the addresses and names in a separate 
myisam table just for searching, though that means a whole new import 
process and also means you'd end up having to do two queries (maybe a 
subquery or join, you'd have to test) - one do to full text search and 
one to get the rest of the data based on the result of the first.

What do your queries end up looking like?

-- 
Postgresql & php tutorials
http://www.designmagick.com/