From: gneuner2@comcast.net
On Tue, 18 Sep 2012 13:24:30 -0700 (PDT), björn lundin
wrote:
>Den tisdagen den 18:e september 2012 kl. 21:57:14 UTC+2 skrev Erland
Sommarskog:
>
>>But you should not use SELECT * in production code.
>
>Why?
To insulate the client (as much as possible) from future changes to
the table(s). You always should specify the columns you want in the
order you want them.
>The system is in Ada, and being in Ada it is strongly typed.
>That means we use some kind of struct, with members
>that corresponds to the fields of a table.
How language variables are bound to the query is not relevant.
>We want to fill the whole struct, because i project adaptions,
>they might want to use a field that we do not use in standard.
>And then, we find the quality of the system increases a whole lot,
>if we get all the data out, instead of just getting the data we want rigth
now.
>Ie fill all the struct members, or else someone will look at an empty field.
>(Yes the y should check this, but experience shows otherwise)
>
>Besides, the select * are the simple ones, since we have routines that fills
that struct
>in correct order.
>
>select a,b,c, from d
>are farr worse, since that tends to be
>
>get(a,varA);
>get(c,varC);
>get(b,varB); <--fail because we got B first.
This makes no sense to me ... it may be an artifact of the library you
are using.
In cases not involving long fields ( text, blobs, arrays ) the DBMS
should return all the requested fields in a single fetch ... stepping
through with a debugger you will see individual calls to populate your
bound variables, but the data is all together in the retrieve buffer.
Individual fetches may be necessary for long fields, but this is
library dependent.
George
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
