Re: SQL Readability.. (was Re: most powerful php editor)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message ----- From: "Larry Garfield" <larry@xxxxxxxxxxxxxxxx>
To: <php-general@xxxxxxxxxxxxx>
Sent: Saturday, January 27, 2007 12:18 AM
Subject: Re:  SQL Readability.. (was Re: most powerful php editor)


I have long since given up on raw insert/update/delete statements as the
syntax is all kinds nasty. These days I just do this, which is even easier
and more powerful:

http://www.garfieldtech.com/blog/simplifying-sql




I tried the following:

insert('sometable',array('when' => mktime(0,0,0,2,1,2007),'if' => true));

which produced the following SQL statement:

INSERT INTO sometable (when) VALUES (1170284400,1170284400)

The problem is that PHP types do not correspond to SQL types. Though a boolean does identify itself as such, a date never does. Your switch() on the gettype() of the value misses the type 'boolean' so it falls through the default: case which then appends whatever was left from the previous pass. However, even adding a case for type boolean there is no way to recognize dates since they are no more than integers for all PHP cares. Finally, what happens with an expression that produces a sort-of boolean, like anything non-zero for true?

Those are the reasons I used type modifiers in my BuildSql function (http://www.satyam.com.ar/int/BuildSql.php), I couldn't rely on PHP figuring them out correctly. This also allowed me to expand those modifiers to optional positional modifiers and null handling ones.

I even tried to query the SQL engine to report them back, but that was also unreliable, MySql for one, reports the type of what it used to store it, not what you declared them to be. Thus, for a boolean field it will report integer, but if you try to store a number other than 0 or 1 it then complains. So, unable to get reliable information from either end, I decided on stating the type explicitly on the query string.

Satyam


On Friday 26 January 2007 10:03 am, tg-php@xxxxxxxxxxxxxxxxxxxxxx wrote:
My contribution to the insanity..  INSERT statements made easy:

$genericQY = "INSERT INTO MOD_LMGR_Leads ("; $genericQYvalues = " VALUES
("; $genericQY .= " FirstName,";                   $genericQYvalues .= "
'John',"; $genericQY .= " LastName";                     $genericQYvalues
.= " 'Smith'"; $genericQY .= " )";
$genericQYvalues .= " );"; $genericQY .= $genericQYvalues;
$genericRS = mysql_query($genericQY);


I use this structure so if I decide that I don't need certain data I can
comment out a single line to remove the column name and corresponding
value. Also helpful for making updates to column/value pairs and not worry
about the dreaded error involve # of columns not matching.

Only things you have to watch for:

1. Make sure you don't have a comma on the last item
2. Make sure you have spaces where appropriate so when it concatenates the strings, you don't get stuff crammed together (not really an issue with the
INSERT statement, but I try to keep a consistant practice with all my
queries so I don't slip up..   SELECT columnsFROM tableWHERE something =
something is where it really gets ya if you forget spaces.. just as an
example) 3. Make sure to remember to concatenate the "query" and "values"
parts

I like to think this is a little "outside the box" thinking since common
practice is "one command, one line" or "total chaos" hah.

Any comments on improving this or other unique stylistic ways people like
to design their code?

-TG


= = = Original message = = =

On Wed, January 24, 2007 8:07 pm, Robert Cummings wrote:
> On Wed, 2007-01-24 at 18:23 -0600, Richard Lynch wrote:
>> On Wed, January 24, 2007 7:41 am, Roman Neuhauser wrote:
>> > # sancar.saran@xxxxxxxxxx / 2007-01-24 13:57:03 +0200:
>> >> and also in these days I'm looking for 19 inch (or more) wide LCD
>> >> sceerns to able to fit longer lines in my screen...
>> >
>> > Number of reading errors people make grows with line length,
>> > this has been known for as long as I remember.  You're increasing
>>
>> the
>>
>> > probability of bugs in the code, and get tired sooner because
>> > following
>> > long lines requires more energy.
>>
>> I believe those results are specific to what is being read.
>>
>> Surely it's easier to read:
>>
>> SELECT blah, blah, blah, blah, blah, blah, blah, blah, blah
>>
>> if it's all on one line, no matter how many fields there are, while
>> trying to read the code as a whole.
>>
>> Sure, it can be "hard" to find/read the individual field names, on
>> the
>> rare occasion that you need to do that...
>
> Dear Mr Lynch, normally I highly respect your commentary on the list,
> but today I think you've been-a-smoking the crackpipe a tad too much.
>
> There is no way in hell one long line of SQL is easier to read than
> formatted SQL that clearly delineates the clause structure.
>
> SELECT A.field1 AS afield1, A.field2 AS afield2, B.field1 AS bfield1,
> B.field2 AS bfield2, C.field1 AS cfield1, C.field2 AS cfield2,
> D.field1
> AS dfield1, D.field2 AS dfield2 FROM tableA as A LEFT JOIN tableB AS B
> ON B.fee = A.foo LEFT JOIN tableC AS C ON C.fii = B.fee LEFT JOIN
> tableD
> AS D ON D.fuu = C.fii WHERE A.foo = 'someValue' ORDER BY afield1 ASC,
> cfield2 ASC
>
> The above line "should" be on one line, but my email client might
> autowrap it. Either way, the following is formatted and is much
> clearer.
>
> SELECT
>     A.field1 AS afield1,
>     A.field2 AS afield2,
>     B.field1 AS bfield1,
>     B.field2 AS bfield2,
>     C.field1 AS cfield1,
>     C.field2 AS cfield2,
>     D.field1 AS dfield1,
>     D.field2 AS dfield2
> FROM
>     tableA as A
>         LEFT JOIN tableB AS B ON
>             B.fee = A.foo
>         LEFT JOIN tableC AS C ON
>             C.fii = B.fee
>         LEFT JOIN tableD AS D ON
>             D.fuu = C.fii
> WHERE
>     A.foo = 'someValue'
> ORDER BY
>     afield1 ASC,
>     cfield2 ASC
>
>
> While the above is contrived, most of us know such examples happen
> quite
> often in the wild. Not only is it easier to read, but the task of
> adding
> or removing selected fields is trivial.

I meant ONLY the SELECT part on a single line.

Only a moron would cram the FROM and all that into the same line.

:-)

$query = "SELECT blah1, blah2, blah3, ... blah147 ";
$query .= " FROM table1 ";
$query .= " LEFT OUTER JOIN table2 ";
$query .= "    ON blah7 = blah42 ";
$query .= " WHERE blah16 ";
$query .= "   AND blah42 ";
$query .= " ORDER BY blah9, blah8 desc, blah6 ";

is what I go for.

The SELECT line is the only one that ever gets all that long, really...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.

--
Larry Garfield AIM: LOLG42
larry@xxxxxxxxxxxxxxxx ICQ: 6817012

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux