When I said that it’s a form of documentation, I was saying that I think it’s 
better to know everything the script is using from the tables right on the SQL 
command, without the need to inspect all the code, for example:



$values = some_fetch_array_thing

[…] bunch of lines of code

echo $values[“column1”];

[…] another bunch of code

echo $values[“column2”];


In my opinion it’s is easier to forget that column2 is being utilized by this 
script, than if it was explicit in the SQL command. Of course, if the lifecycle 
of the array fetched from the resultset doesn’t spread too much, there isn’t 
any problem.


Besides that, I’ve got your points =). The “a.*” thing successfully beats the 
join problem.


One last point: “Of course there are occasions where the database is updated 
and breaks code, in which case specifying all the field names would potentially 
avoid that”, we should only declare in the SELECT clause fields we’re actually 
using along the script, and even if we go with the “*” way the code will broke 
eventually with schema changes.




De: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Enviada em: sábado, 22 de setembro de 2012 12:35
Para: Samuel Lopes Grigolato
Cc: 'PHP List'
Assunto: Re: RES: RES: [PHP] Re: Need help to understand a code


On Sat, 2012-09-22 at 12:12 -0300, Samuel Lopes Grigolato wrote: 

I disagree with you Ashley, some arguments can be found here: 
Using explicit columns names in the select clause is, IMHO, at least a good 
documentation for what is being requested to the database layer.
+1 to Maciek's suggestion, had totally forgotten this one.
-----Mensagem original-----
De: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Enviada em: sábado, 22 de setembro de 2012 11:52
Para: Samuel Lopes Grigolato; 'PHP List'
Assunto: Re: RES: [PHP] Re: Need help to understand a code
Samuel Lopes Grigolato <samuel.grigol...@gmail.com> wrote:
>+1 to bad maintainability of the code.
>As a suggestion, one better solution could be something like:
>class Entity {
>   public $id;
>   public $name;
>$entity = new Entity();
>foreach [...]
>  $entity->$$key = $value;
>And, of course, never ever use "*" in SQL queries.
>-----Mensagem original-----
>De: Matijn Woudt [mailto:tijn...@gmail.com] Enviada em: sábado, 22 de 
>setembro de 2012 11:02
>Para: a...@ashleysheridan.co.uk
>Cc: Ashickur Rahman Noor; PHP List
>Assunto: Re: [PHP] Re: Need help to understand a code
>Op 22 sep. 2012 13:47 schreef "Ashley Sheridan"
><a...@ashleysheridan.co.uk> het volgende:
>> On Sat, 2012-09-22 at 17:43 +0600, Ashickur Rahman Noor wrote:
>> > Hi Ashley
>> >
>> > I am updating some one code. Thanks for the notify.
>> >
>> > Thanks to all. Now I get that.
>> > ----------------------------------------------------------
>> > Dedicated Linux Forum in Bangladesh <http://goo.gl/238Ck>
>> > 2048R/89C932E1 <http://goo.gl/TkP5U> Coordinator - Public Relation 
>> > Cell, FOSS Bangladesh <http://fossbd.org/> && Mozilla Reps 
>> > <http://reps.mozilla.org> 01199151550, 01551151550
>> It's probably fine doing that for your example, as the content coming
>> from the database will be content you expect, but be wary of using it
>> on any of the user-generated arrays like $_GET, or $_POST.
>And a few months/years later you decide to add a new column to your db 
>which has the same name as one of the variables you're already using 
>and the script starts acting very strange...
>People should stop using bad coding habits like these..
>- Matijn
>PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: 
there's nothing wrong with using * in queries.
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

There are plenty of times that you need all fields from a table though. I go by 
the rule that if I need less than two thirds of the fields of a table, then I 
specify the fields I need, otherwise, it's easier to go with *.

I've looked at the link you posted. The join issue is too broad. I use * with 
joins, but avoid the conflicts by specifying the table name, still going by the 
⅔ rule above on a table by table basis. Of course, if there are tables used in 
the join that are not necessary to the actual output, I won't include them in 
the list, but I may do something like this:

SELECT a.a, a.b, a.c, b.*
LEFT JOIN a on a.a = b.a

I would say that if you're in the position of writing the queries then you 
should be aware of the database schema, so using the query as a form of 
documentation shouldn't be a factor. Of course there are occasions where the 
database is updated and breaks code, in which case specifying all the field 
names would potentially avoid that, but procedures should be in place which 
would at least make you aware of such updates to allow you to plan for them.



Reply via email to