Danny's Weblog

Review: PHP & MySQL for Dummies 2nd Edition 2004

This is quite an old book now but I was happy to spot it in my local library. I was actually looking for a PHP book as I more or less know MySQL at least as of a few versions ago, but a lot of the stuff you use PHP for needs to hook up to a database of some kind anyway.

I have already used PHP with MySQL for a couple of little projects, but I was hoping to get a better overview of how to set up and debug a project.

Overall, the book has some surprising omissions. For one thing, no object-oriented features are discussed. For another thing, there is a lot less emphasis on security than I was expecting. For instance "register_globals": I actually did not see any reference to it when I read through the book, and only found it just now when I was looking for the PHP version used for the book. (Most people know about this issue by now, although they might not have in 2004; if you don't, you should probably Google it right away.)

On the other hand, I liked the way it discussed the use of include files to make the code more understandable. I actually had not realized that you could put so much html in them and still have php variables that work (although you wind up depending on a lot of global variables, as opposed to using a bunch of subroutines as I'm used to doing in Perl).

The following is a list of items I noted.

1. p143 Chap 6 Joining comparisons with and/or/xor

"If you are familiar with other languages..." Apparently the "and" form has exactly the same precedence as "&&". That is *not* the same as Perl.

2. p 155 Chap 7 Creating arrays

$capitals = array( "CA" => "Sacramento", "TX" => "Austin", "OR" => "Salem" );

I find myself not really liking either PHP or Perl's fundamental syntax very much. As you can see from the above example, all PHP variables just have a leading "$", whatever they are – scalar, array, hash (although the book just calls a hash "an array ... viewed as ... a list of key/value pairs"). On the other hand, Perl wants you to designate a variable by the variable type it winds up as once you've appplied all the trailing items; eg "$orange[3]" is scalar element 3 of the array "@orange", but scalar "$orange" is a separate variable which has nothing to do with either of the former.

I prefer the object style, something like this: "@orange.element(3)" or even "orange.element(3)".

3. p 155 Chap 7 Viewing arrays

I was interested to see the example of the "print_r" function to print the contents of any array:

print_r($capitals);

I had no idea that PHP had this built in and it would certainly have made some of the debugging I've done easier.

Now I think about it I wonder how PHP really knows whether to display an array as pairs or individual elements. Presumably it always displays them as pairs; if there's a mixture of numeric and text keys... I leave that as an exercise for the reader.

4. p 156 Chap 7 Sorting arrays

The way "sort" and "asort" work seems a little arbitrary, although handy.

5. p196 Chap 8 Sending SQL queries

I often run into problems when I start forming a query string to eventually send off to the SQL server. For instance, I usually try to leave a semicolon on the end, even though that never works.

So it's good that the book has a section on this, However, I was surprised to see the following example:

$query = "UPDATE Member SET lastName='$last_name'";

The wacky thing is the single quotes around the variable name, of course. I think the way it works is that the quotes prevent PHP looking up the value of the "$last_name" at the time you assign the string to "$query". However, it *will* look it up when the string is inserted in "mysql_query":

$result = mysql_query($query);

I can't remember how I handled this problem before! I think I threshed around until something worked and then tried to put the horror behind me.

6. p199 Chap 8 Getting and using the data

This page has an example of using "extract($row)", which very neatly produces and sets all the variables you usually need from a row you get from the database. Example:

$row = mysql_fetch_array($result, MYSQL_ASSOC);
extract($row);

So if one of the fieldnames for the row was 'password', the value of that field for this row will be in $password.

When I've had to do something like this in the past, I've had to tediously create a bunch of variables individually, as well as doing an assign which is prone to error (especially when you modify the table definition).

7. p 302 Chap 11 Adding data to the database

The book suggests using the LOAD command to recreate a table easily while debugging:

LOAD DATA LOCAL INFILE "pets" INTO TABLE Pet;

Neither this, nor the section in Chap 4 which this section refers to, clearly makes the point that the LOAD statement is very limited in where it can read the data file from. My understanding is that for security reasons, the file *must* be in the same directory as the data file is located in; the text briefly says this, but I don't think the book has ever referred to *how to find* what the directory is. I think when I first ran into this many years ago, I had to create a table with a wacky name, run updatedb, and then locate to figure out where the data files are! (Try looking in /etc/mysql/my.cnf.)

Also, although it's nice to use LOAD sometimes because it can understand files that you can create in Excel – ie way before you have the rest of the database software set up to enter data in the required format – I think the author should have referred to the "mysqldump" command too, as well as the reverse of the LOAD command:

SELECT * INTO OUTFILE 'file_name' FROM tbl_name

8. p 320 Chap 11 Adding pets to the catalog

Listing 11-6 includes the following code:

if (@$_POST['newbutton'] == "Return to category page" or @$_POST['newbutton'] == "Cancel")

I was about to grumble about how wacky this syntax was, and then I remembered. This is explained on p124; the "@" sign has nothing to do with arrays, it just tells PHP to suppress error messages if the variable is not defined!

There are copious notes on the listing which do not include this point. Perhaps everyone else was paying more attention on p 124.

9. p 337 Chap 12 Building the login table

I mention this tiny point only in order to show that I sometimes *do* pay attention: the text says "MySQL will not allow two rows to be entered with the same loginName and loginDate". That "loginDate" should read "loginTime" to match the rest of the text.

10. p 337 Chap 12 Adding data to the database

This paragraph mentions "to test the programs while you write them you need to have at least a couple of members in the database". This deserves rather more consideration than the book gives it.

For instance, you need to do testing continuously, even after the database has gone live: you need to keep making sure all of the existing features are *still* working while you continue to add features. So you may need to retain a lot of artificial corner cases in the tables, like a customer who makes an order which includes 80 items, or a customer with a foreign address to make sure your new invoices still work with them, even though your company still hasn't actually had a foreign order.

Sometimes I actually include a flag field in every table to identify test records.

Copyright © 2003-2009 Alternate Worlds Publishing, Boston MA USA