Mapping Column Names to results using DBI

[Lance Ellinghaus]

There are other reasons to do a "SELECT * FROM ..." and not "SELECT x,y,z FROM
..."

For example, if you have columns that are only valid depending on other values
in the returned row you would want to pull them all over and use only the ones
that are valid. When you are moving around NULL columns, there is very little
overhead.

I have a table that has over 75 columns and the columns that are valid are based
on a number of columns in the row. The other columns are NULL and thus take
minimal overhead to maintain and query against. That is why I wrote a that
little bit of code I posted earlier today to convert the returned row into a
dictionary. Makes it easier to use.

Lance

-------From: "Gordon McMillan"  on 01/19/2000 10:31:47 PM-------

From: "Gordon McMillan" <gmcm at hypernet.com>
To: Timothy Grant <tjg at avalongroup.net>, Python People <python-list at python.org>
cc:
Subject: Re: Mapping Column Names to results using DBI






Timothy Grant wrote:

> Aahz Maruch wrote:
>
> > Try "SELECT x, y, z" instead of "SELECT *".
>
> I knew it couldn't be that simple...
>
> I must be missing something

DBs return the columns in the order requested. So you will
always get tuples of (x,y,z).

"Select *" is like "from module import *" - something you
should really only do in interactive mode.

I'll agree that this creates a distasteful coupling between the
SQL code and the Python, but performance makes it more
palatable.



- Gordon

--
http://www.python.org/mailman/listinfo/python-list