kdeff Posted April 28, 2013 Share Posted April 28, 2013 This question comes from an efficienct standpoint. Why does SQL (I've used PGSQL and MySQL) always return variables as strings to PHP? This seems horribly inefficient, as the SQL server will have to transmit bulky string data to PHP when representing anything. Why pass the string "FALSE" to php when a 1 bit boolean would suffice? Quote Link to comment Share on other sites More sharing options...
trq Posted April 28, 2013 Share Posted April 28, 2013 Can we see some examples of your data? Quote Link to comment Share on other sites More sharing options...
kdeff Posted April 28, 2013 Author Share Posted April 28, 2013 This is not specific to my project. Am I wrong in my assumption - is there a way to return variables to PHP without strings? Quote Link to comment Share on other sites More sharing options...
trq Posted April 28, 2013 Share Posted April 28, 2013 The only time you would get the string "false" is if your data was the string "false". If you store your booleans as 1's and 0's (in a tinyint(1) field) they will equate to true and false in php. Quote Link to comment Share on other sites More sharing options...
ignace Posted April 28, 2013 Share Posted April 28, 2013 (edited) The reason that SQL returns everything as a string except NULL which since a certain PHP version, I think 5.3, actually returns NULL, is because that it simply can't translate the types correctly. It can't translate a TINYINT, a SMALLINT, a MEDIUMINT, a BIGINT, a DECIMAL, a DATETIME, a YEAR, a TIME, a VARBINARY, a DOUBLE, an ENUM, a SET, ... And these are just the ones that I can think of out of the top of my hat. Not to mention any custom data types in MySQL. So thus since it can only translate about 2 or 3 types correctly it simply doesn't bother and it's expected of the user to do this conversion themselves if desired. Now you may wonder why I included TINYINT, SMALLINT, MEDIUMINT, ENUM, YEAR, etc. This is because you probably don't understand type translation between languages. When the column is a tinyint then in PHP it should be the equivalent not a 32-bit signed integer or you will get problems when you want to update the row (where this translation would also exist, and you can't fit a 32-bit signed integer into a tinyint). The same goes for example a SET, which would be an array where you can only add certain values. SQL: SET('foo', 'bar', 'bat', 'baz') PHP: $mySet[] = 'world'; // error: world is not in set('foo', 'bar', 'bat', 'baz') Edited April 28, 2013 by ignace Quote Link to comment Share on other sites More sharing options...
Barand Posted April 28, 2013 Share Posted April 28, 2013 This question comes from an efficienct standpoint. Why does SQL (I've used PGSQL and MySQL) always return variables as strings to PHP? This seems horribly inefficient, as the SQL server will have to transmit bulky string data to PHP when representing anything. Why pass the string "FALSE" to php when a 1 bit boolean would suffice? It returns 1 for true, not "TRUE" mysql> SELECT 5=5 as result; +--------+ | result | +--------+ | 1 | +--------+ Quote Link to comment Share on other sites More sharing options...
fenway Posted May 5, 2013 Share Posted May 5, 2013 This really up to the driver -- MySQL faithfully returns types. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.