Furthermore, you could have a select that calculates values that come
from many different tables. A select is a transformation on data in the
tables. The columns in a select can have an infinite number (well,
lots, anyway) of relationships to the columns in the tables, especially
when you consider that the resultset columns could be the output of
formulas applied to 0-N different table columns.
eg:
select a as b, c*a as d, e+c as f, 3.14159 * 42 as j, 666 * b as k
from foo as c3, bar as c2, pil as c1
where ...
So, even IF that information were available, some columns in your
resultset might come from 1, many, or no columns in the database.
I'm not sure that what you want to do makes any sense in a real-world
sort of way. However, it would make sense to map a resultset to a class
IF that class generated the SQL to being with, or IF the developer of
that class already knew what columns would be in the resultset. That is
what we do. We define a SQL query (which is constructed by the code
itself using SQL rules and table+column definitions, and also regression
tested against a live DB before we release). That query's output is
then associated with a class that knows what to do with it (how to
display it, etc.).
Hope this helps.
Dave Cramer wrote:
> select a as b, c as d, e as f from foo as c1.
>
> The backend is the only one that knows which table which came from.
--
Matt Mello