For the SQL gurus: Is this practical? Is it even possible?

Fellow geeks, geekettes, and gurus:

Consider the following scenario:

We have the following physical files, FOO, BAR, BAZ, GAZONK, and QUUX. The records in FOO are keyed on a unique 9-digit number, while BAR, BAZ, and GAZONK (all with completely different structures) are keyed on a 19-digit number that is unique across all three files.

QUUX is a file that associates records in FOO with records in BAR, BAZ, and GAZONK. Its records consist of a 9-digit FOO key, a 19-digit BAR/BAZ/GAZONK key, and a code to indicate which of the three files the 19-digit key can be found in. QUUX is keyed on the FOO key first, then the BAR/BAZ/GAZONK key; it has a logical file, QUUUX, in which the key precedence is reversed.

Let us further suppose that FWEEP is a field in BAR, BOZ is a field in BAZ, and GRIFFY is a field in GAZONK.

Now suppose we are looking for all the records in FOO that are associated with at least one BAR record in which the FWEEP = 2, at least one BAZ record in which BOZ = "SPAM," and at least one GAZONK record in which GRIFFY = 3.141592653589793.

There are no direct links between any two of FOO, BAR, BAZ, and GAZONK. The only way to get from BAR, BAZ, and GAZONK to FOO is through the QUUUX logical of QUUX; the only way to get from FOO to BAR, BAZ, or GAZONK is through QUUX.

Now the questions:
1. Is it possible to write (or, since we want arbitrary searches, programmatically generate) a single SQL SELECT, under these conditions, that would implement our search, and run on OS/400 SQL?
2. Is it practical?
3. Would it produce results in a reasonable amount of time (say, sometime this decade) without inordinately tying up the processor?

If I sound like the scenario is not my idea, and like I'm very skeptical of its value, it's because it isn't, and I am.

--
JHHL