Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #1301

Re: HashDbase and parallel hashlist...

From Robert Wessel <robertwessel2@yahoo.com>
Newsgroups comp.programming.threads, comp.programming
Subject Re: HashDbase and parallel hashlist...
Message-ID <h3ngf8p4good4bc608ntfnpn2i2l94atjd@4ax.com> (permalink)
References <kd6n55$fb1$1@dont-email.me> <kd98fq$h1k$1@dont-email.me>
Organization Forte Inc. http://www.forteinc.com/apn/
Date 2013-01-17 14:30 -0600

Cross-posted to 2 groups.

Show all headers | View raw


On Thu, 17 Jan 2013 11:22:11 -0800, aminer <aminer@toto.ca> wrote:

>Hello,
>
>
>I have a question for you, i want to support SQL Joins in my
>HashDBase , but suppose i have the following
>SQL statement:
>
>
>"select  editors.ed_lname,editors.city,publishers.city
>
>from editors,publishers
>where editors.city = publishers.city
>and publishers.pub_name = 'Algodata Infosystems' "
>
>
>So to execute the following SQL join on my HashDbase
>and to optimize it more, I have to start with the
>
>where publishers.pub_name = 'Algodata Infosystems'
>
>And the field publishers.pub_name has to be indexed first to
>optimize more this join , and after we have filed the array
>we have to execute the "where editors.city = publishers.city"
>
>and then scan the array and compare publishers.city with  editors.city.
>
>
>Am i correct with this ?



That would be one way to do it.  Remember that you can get multiple
matches in that stem (IOW, there may be multiple editors that match a
given publisher's city (requiring multiple outputs).

OTOH, the question of how to use indexes, and which table to scan
first depends on the data.  For example, if the publisher table was
small, it might be best to run both publisher and editor in city
order, matching them up (IOW, a traditional match/merge except for
needing to back in the second table up to handle multiple city
matches), and then discarding ones where publisher.name was wrong.

Remember that an SQL join works as if you had built the cartesian
product of the input tables, and then selected the resulting tuples
that matched your "where" criteria.  That's a bad to to actually
implement things, except for very small tables, but it gives you an
easy way to visualize the required result.

Back to comp.programming.threads | Previous | Next | Find similar


Thread

Re: HashDbase and parallel hashlist... Robert Wessel <robertwessel2@yahoo.com> - 2013-01-17 14:30 -0600

csiph-web