seaching a list...

[bruce]

hi larry...

thanks for the reply...

the issue i'm having is that i'm going to have to compare multiple rows of
information to the information in the db. so essentially i'd have to do a
hit to the db, for each row of information i want to compare if i did it
your way... (which was what i had thought about)

the issue of doing the string/list compare/search is that i can get
everything from the db with one call... i can then iterate through memory
for each of my row information that i'm searching to see if it exists in the
db...

memory searches should be faster than the network overhead, and the
associated multiple db calls...

-bruce

-----Original Message-----
From: python-list-bounces+bedouglas=earthlink.net at python.org
[mailto:python-list-bounces+bedouglas=earthlink.net at python.org]On Behalf
Of Larry Bates
Sent: Thursday, August 10, 2006 4:28 PM
To: python-list at python.org
Subject: Re: seaching a list...


bruce wrote:
> hi...
>
> i'm playing with a test sample. i have somethhing like:
>  dog = mysql_get(.....)
>  .
>  .
>  .
>
> such that 'dog' will be an 'AxB' array of data from the tbls
>
> furher in the test app, i'm going to have a list, foo:
>  foo = 'a','b','c','d'
>
> i'm trying to determine what's the fastest way of searching through the
> 'dog' array/list of information for the 'foo' list.
>
> should i essentially make dog into A lists, where each list is B elements,
> or should it somehow combine all the elements/items in 'dog' into one
large
> list, and then search through that for the 'foo' list...
>
> also, in searching through google, i haven't come across the list.search
> function.. so just how do i search a list to see if it contains a
sublist...
>
> my real problem involves figuring out how to reduce the number of hits to
> the db/tbl...
>
> thanks
>
> ps. if this is confusing, i could provide psuedo-code to make it easier to
> see...
>
>
>
>
You should use the database for what it is good at storing and searching
through data.  Don't read all the data from a table and search through it.
Rather, create indexes on the table so that you can locate the data quickly
in the database by passing in something you are looking for and let the
database do the searching.  I can promise you this will almost always be
faster and more flexible.  Something like:

Assume the columns are called rownumber, c1, c2, c3, c4 and the table is
indexed on c1, c2, c3, and c4.  This will happen almost instantly no matter
how many rows you are searching for.

select rownumber from database_table
       where c1="a" and c2="b" and c3="c" and c5="d"

It takes one "hit" to the db/table to return the rowindex that matches.

-Larry Bates
--
http://mail.python.org/mailman/listinfo/python-list