Re: beginner's question

Two things:

1. The "connection" (join) is always part of the WHERE clause in a given query.
2. You don't necessarily want to make that join part of the query. It depends on what you are trying to do.
3. You may want a left, right, or full outer join, or perhaps even a non-equijoin.

In any event, merely reading the fact (either from the data dictionary or from a screen) that tables are related is not sufficient cause to include this fact in a query, nor is it possible from this information to conclude in what way it should be included in a query. This is one set of reasons why it always takes a human to create a query.

Sandy Pittendrigh <sandy_at_nervana.montana.edu> wrote in message news:3846A1FE.B27718EB_at_nervana.montana.edu...
> For any schema where any table can (somehow) be connected
> to any other table through a connected path of
> primary_key/foreign pairs, it must be possible for an
> external parsing routine to read the data dictionary and
> construct a connected, directional graph of the entire
> schema.
>
> Given this, and also given an arbitrary collection of GUI
> query screens, where each widget in the query screen can be
> toggled on or off, and where each widget in the query screen
> is associated with a (tablename, column_name, data_type)
> touple, then it must be (is it?) possible for that external
> parsing routine to read the "widget state" of the screen
> and dynamically construct the "foreign_key=primary_key"
> clauses needed to make a logical select statement.
>
> In other words, any query screen that interactively prompts
> for the "SELECT columns" part of a select statement as well
> as the "WHERE constraints" part of the select statement, the
> only hard part left is to add in the "link this table to
> that table" clauses. The programmer who designed the schema
> can do this. But what about a parsing routine that only
> knows the state of the query screen?
>
> --
> /* Sandy Pittendrigh >--oO0>
> * sandy_at_nervana.montana.edu
> * http://nervana.montana.edu/~sandy
> */
Received on Thu Dec 02 1999 - 00:00:00 CET