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

I'm truly amazed that there even IS a solution that doesn't involve having multiple open cursors into QUUX/QUUUX.

Thanks. Even though the very existence of a solution tends to torpedo a few of my arguments *against* such an arrangement (my own preferred solution would have BAR, BAZ, and GAZONK keyed directly to FOO, with an additional keyfield to provide sequencing and uniqueness).

Going back to the above scenario (and I'm not really looking for an example; just whether or not this added layer of complexity kills it), suppose we add files FIZMO, with an 11-digit key, and PROSSER, which links records in FIZMO to records in FOO, with many-to-many capability. PROSSER is uniquely indexed three different ways: on the FOO key and the FIZMO key; on the FIZMO key and the FOO key; on its own 13-digit key.

Now, suppose the field in QUUX which was formerly only 9 digits, and could only contain a FOO key is now a 13-digit field that could contain a FOO key, or a FIZMO key, or a PROSSER key. And suppose we have a bunch of files similar to BAR, BAZ, and GAZONK, all tied to QUUX/QUUUX. Some of them only have records linked to FOO; some only have records linked to FIZMO; some only have records linked to PROSSER; some might have records linked to more than one of those three files, but in all cases, the linkage is indirect, through QUUX/QUUUX. Do we still have something for which any arbitrary query (looking for FOO, FIZMO, or PROSSER) can be programmatically coded and executed sometime before heat-death of the universe?

Now suppose both fields in QUUX/QUUUX are 19 digits, and QUUX can arbitrarily link any record in any file of this system to any record in any other file of this system. Are we dead yet?

Again, I'm not really looking for an example; just an idea of whether this concept would remain practical by the time it was expanded to the size of the real application (with thousands of records in each file), or would degenerate into a total mess.