PHP and MySQL Web Development

PHPee writes ""Learn the concepts and build the applications..." - PHP and MySQL Web Development is a well-written web developer's guide to using these open source products to create dynamic websites quickly and easily. This book covers everything you need to design, build and debug your own website from the ground up. Special attention is paid real-world issues, like database normalization and site security. Overall, a great reference for beginner and more advanced programmers alike." Read on for the rest of his review. PHP and MySQL Web Development author Luke Welling & Laura Thomson pages 896 publisher Sams rating 9/10 reviewer PHPee ISBN 0672317842 summary From hello world to e-commerce in under 900 pages...

The authors of the book (Luke Welling and Laura Thomson) do a great job of introducing new programmers to the world of PHP and MySQL. The book is divided into five sections which take the beginner programmer through many lessons in solid, secure web programming.

Part One Starting with the "PHP Crash Course," the reader quickly learns the syntax and language constructs of PHP. The following five chapters focus on topics such as arrays, string manipulation, writing functions and object-oriented PHP. This provides a solid foundation in PHP before moving on to the intricacies of MySQL. This section is very hands-on, using realistic examples, which could be expanded upon as skills progress.

Part Two The following section focuses on MySQL, starting by explaining the advantages of a relational database vs. a flat file storage system. The book assumes no knowledge of databases, explaining simple terms such as tables, columns, rows, etc. It then progresses on to the fun stuff, like designing databases for the web and normalization.

Particular attention is placed on MySQL's privilege system, including proper use of the GRANT/REVOKE commands to give/take away rights for database users. This section is quite detailed and offers a lot more information than I expected. The various column types and associated keywords are also examined in great detail, providing the reader with a solid understanding of MySQL's main features.

Part Three Part Three of the book examines the issues associated with running an e-commerce site. This section is nicely done, looking at common mistakes and how to avoid them. These include things like server security, data backups, keeping detailed logs and dealing with other threats, such as crackers, denial of service attacks and destruction of data. Authentication methods and encryption schemes are also thoroughly covered.

Part Four This section of the book expands on part one, delving into some more advanced PHP techniques, such as interacting with the file system, using network and protocol functions and generating images on the fly with the gd library.

This section also looks at PHP's powerful session functions, including using sessions with authentication and the use of cookies.

Part Five This is by far the most exciting section of the book. Here the reader is presented with seven real-world examples that utilize most of the issues presented throughout the book. These practical projects are presented in an easy to follow manner. The basic problem is presented, and then a solution is proposed. The authors take you from start to finish, outlining the database design, necessary files and functions and show you how to tie it all together. They are also very good at pointing out possible enhancements or alterations, hopefully inspiring the reader to develop their skills and create something beyond the scope of the book.

The seven projects are as follows:

• User authentication and personalization
• Shopping cart
• Content management system
• Web-based email service
• Mailing list manager
• Web forums
• Generating personalized documents in PDF format

Each of the projects has a real-life application, and can easily be modified to fit the needs of almost any website. The shopping cart application is quite complete, and could serve as a basic cart as-is. The web-based email service incorporates the IMAP and POP3 protocols in an easy to understand manner. And the web forums project discusses the complexity involved in creating a threaded discussion board. It even refers to slashdot as a "fantastic example of a popular website that uses discussion boards" :)

Other info: There are a few minor typos and errors in the book, but nothing to get angry at the authors about. Most of them are quite negligible, but may still create some frustration for beginners. (For example, they make reference to a function isempty(), which does not exist in PHP. The real function is simply named empty()...) Small errors like this may create some confusion, but the errata listed on the author's website are quite helpful, yet not all-inclusive.

The appendices do a good job of showing you how to install apache, PHP and MySQL to get up and running under both Linux and Windows. The book also comes with a CD that contains a PDF version of the entire text, all code examples, and copies of PHP and MySQL so you can set up your own development environment at home.

Overall The book is targeted toward intermediate to advanced programmers, but I'd suspect it would be more useful to the beginner to intermediate group. However, the book is organized in a way that accommodates beginners and more advanced users. If you have previous programming experience, you can probably skip some of the early chapters and jump straight into the larger projects. It's a handy reference book, nonetheless. This book covers almost everything you need to know to learn how to use PHP and MySQL to create dynamic, database-driven websites in no time at all. It does an excellent job presenting some real life projects, and the emphasis on security and clean code is consistent throughout the entire book.

You can purchase PHP and MySQL Web Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

online user comments on

[stonebeat.org]

mysql.com and php.net are the best reference you can ever get.

Re:online user comments on

[Ron Harwood]

I will agree to an extent...

When I am writing a web-app... I will often go to their sites as a reference... however, I find that the examples are sometimes lacking.

MySQL's site is rather poorly laid out and makes assumptions that you already know all there is to know about MySQL - pretty good reference, poor for learning from.

PHP's website is excellent - again though - not a great learning source... there are user submitted examples - but they aren't moderated or proofread... so are often garbage.

I think I've learned more about PHP/MySQL from books and PHPBuilder than I have from the actual PHP/MySQL sites...

Excellent Book

[lpret]

I have always been an O'Reilly kind of guy, but I picked this book up and was very impressed. I'm probably catagorised as an intermediate programmer, and I found it intuitive and easy to pick up. Also, the book assumed you had some grasps of the concepts which kept it from being redundant and boring. A very good book if PHP is your second or third language.

Apache Fun

[Big Mark]

"Learn the concepts and build the applications..."

Then realise, after many sleepless nights of trying to get it to work, that your Apache build is bugged.

-Mark

Old News

[Anonymous Coward]

This book has been out for a couple of years now. Don't know why this needs to be posted.

I Have This Book

[Acidic_Diarrhea]

I got this book over a year ago and I must say that, while I enjoy it and it is well written, I would agree that it is more for an inexperienced programmer. As someone who knows a bevy of languages, the hand holding wasn't really useful and ultimately if I had a problem with PHP syntax, I didn't go to the book, I went to the PHP docs from php.net. I find the online documentation for PHP is some of the best documentation I've ever seen for a language. I did use the MySQL sections a bit just to check on syntax for MySQL commands, specifically setting up user permissions and such. This was, in part, due to the documentation provided by the MySQL people - which is a bit lacking. But the presentation of the information on MySQL was always set up as sort of a walkthrough of your typical needs. When you need to stray from this, that's when you need to consult other sources OR start guessing. I suppose I could have benefitted more from a book purely on MySQL, use the online PHP docs, and maybe save some money! Oh, one other complaint I had was that they attempted to cover some aspects of SQL but really didn't provide enough of a description to be able to 'know' SQL. And they didn't hit normalization in any effective way whatsoever but, luckily, I already know all I need to know about normalization. I guess to sum up my review: it's a good book if you are implementing something simple and don't already know how to program that well. But if you've got a large-scale LAMP project it might be best to get some standalone reference texts for each. And now, I'll suggest a few:
Fundamentals of Database Design is a great book for learning about normalization of a database into any of the many forms.
MySQL by Kofler is my favorite book on MySQL.
As for a pure SQL reference, just go with O'Reilly. Have a great day!

Target market

[noz]

"Overall, a great reference for beginner and more advanced programmers alike."

I'm not a big fan of books that are targeted at both beginner and advanced programmers. Authors and publishers attempt to target their product at all available readers, but I find myself skipping chapters in some books (either early or late). What have you found?

Re:Target market

[hanzwurst]

I'd completely agree to you. Furthermore, I'll never understand how one can prefer printed documentation in favor of online-documentation. There are some strange people out there ;)

This book covers almost everything you need to know to learn how to use PHP and MySQL to create dynamic, database-driven websites in no time at all.

This disqualifies this book for me. In my opinion, there is a lack of books for advanced PHP programmers. You'll find plenty of write-your-own-webshop-in-2-mins-books, but I'd like a book covering security or performance for example. Any suggestions?

Re:Target market

[Brandon T.]

Take a look at "Web Application Development with PHP 4.0", by Ratschiller and Gerken. This book is primarily intended for advanced php programmers and contains topics on advanced topics such as bitwise operations for storing values in databases and writing your own database-driven session handlers to replace php's.

Brandon

www.php.net

[Anonymous Coward]

To be honest I'm not sure you really need a book to learn PHP or MYSQL, both of these have excellent websites which cover their respective topics extremely well.

I have bought a few PHP books, the wrong ones I think, and none of them have come close to being as informative or as useful as the website.

The other thing with PHP is that there are now so many free projects using PHP it is often a lot better to look at they are coded, I think you gain a lot more pratical knowledge this way than you could glean from any book no matter how exhaustive.

I am of course speaking from the perspective of someone who was familiar with programming and scripting before I came to use PHP but maybe it is better to get a book or learn programming theory before you come to apply it to a language. Although languages are different once you know what you want to do you can usually apply your general knowledge to the language without too much trouble and in the process I think gain new persepectives on what is a right or a wrong way to do something.

Re:www.php.net

[dboyles]

The other thing with PHP is that there are now so many free projects using PHP it is often a lot better to look at they are coded, I think you gain a lot more pratical knowledge this way than you could glean from any book no matter how exhaustive.

The only problem I have with this is that sometimes new programmers want to use this copy-and-paste style coding before they really understand the language. I mean, most /. folks know the benefits of reusing code in this way, but doing so without knowing what it's doing is risky business. I don't think I need to explain why.

For that reason, there certainly is a place for beginner books, as this one seems to be.

Loved it... and still use it even when not using..

[gilxa1226]

This book is great... not only as a beginning to PHP and to mySQL, but also for combining the two into an extremely useful tool. I used the book for an independent study I did my junior year of college, and I still pull it out for references even when PHP is not the language that I'm using to interface with my mySQL server. It is great and easy to read.

Phpp

[Anonymous Coward 1]

I hardly ever use perl anymore, first of all I find that phphome is amazing, a really great resource, and second, exactly what can you do with perl that you can't do with php??? Third I find it about 3X profitable to just use static pages with some basic markup.

Now, I'll admit, I used to be rather pro-perl, but as they say, A programmer who's under 30 and uses php has no heart, and a programmer over 30 who doesn't has no brain!

Not ready for prime time

[tuxlove]

PHP is essential, but MySQL is not stable enough for a real 24x7 web service. The lack of stability of /. probably a good example of this point. And my experience at work also bears this out. We're going to greath lengths to replace all MySQL servers with something else which is actually reliable.

Someone showed me a quote on the web that said something like, "MySQL is quite stable - I'm able to run for 100 days without restarting it!" That's hardly the definition of stable in my book. Unless you're a hobbyist, or have very few servers and can tolerate some unscheduled downtime in your service, there is no place for MySQL in a web service. Especially when you've got dozens, or even hundreds, of SQL servers. It becomes extremely burdensome to keep them all running, and to write software which is tolerant of SQL server downtime.

Re:Not ready for prime time

[u-235-sentinel]

mySQL not ready for prime time?

Have you checked Yahoo's financial news lately? They are running mySQL for their backend. Sounds like they are pretty happy with it. Oh, and it runs 24x7 also :D

I believe there was a slashdot article last month which mentioned this also. Very impressive.

Re:Not ready for prime time

[bellings]

Especially when you've got dozens, or even hundreds, of SQL servers.

You have hundreds of servers, each running a seperate, individual copy of MySQL, with multiple databases on each?

If I were you, I wouldn't worry about the uptime of your MySQL instances -- in my experience, that's rarely a problem. I would, however, worry about the intellectual capital you're expending to catalog and manage hundreds, or perhaps thousands, of databases.

Simply dealing with the administration requests for database permissions and roles must be a full time job for several people. The dozens of people required to understand and manage the schemas for those databases must be a huge drain on your organization.

I suspect that using Oracle or MS SQL would save your organization literally millions of dollars a year, simply because of the improved management interfaces and flexibility of the databases as a whole.

Re:Not ready for prime time

[scottyboy]

I really don't know what you are talking about - though I concede that MySQL is far from perfect, I have no problems running it 24/7 primetime, and yes, I run it on Linux *and* Solaris. It's uptime is admirable and it is fine for a medium-sized web service.

Your "there is no place for MySQL in a web service." sounds like simple chest-beating posturing to me.

We've had more trouble with disk burn-outs, and we've not had very many of those.

Re:Not ready for prime time

[delta407]

MySQL is not stable enough for a real 24x7 web service.

Yahoo disagrees.

Does PHP need a good debugger?

[Dthoma]

I know this is going to sound terribly odd (and might make me come off as a total n00b) but I'm going to go out on a limb here and say that PHP doesn't need a debugger (at least not yet). Really, I've been playing around with PHP for months now, playing around with string functions, loops, databases, recursion, and the like and I've never need any debugging tool more advanced from echo.

I've found that it's very hard to make insidious and hidden errors in PHP if you just plan your code well and are familiar with the language. Most of the errors I make in PHP tend to be of the "Oops, missed out a semicolon" variety, so the simple one-line error "Parse error at line X" is generally enough for me. Even the most complex errors I make (such as when mysql_num_rows complains about a variable not being a MySQL result) is due to something boneheaded and reasonably obvious, like forgetting to connect to a database or missing out a line of code.

Even without a debugger, I've never had to puzzle over any PHP problem for more than a few hours.

Re:Does PHP need a good debugger?

[Frater 219]

I know this is going to sound terribly odd (and might make me come off as a total n00b) but I'm going to go out on a limb here and say that PHP doesn't need a debugger (at least not yet). Really, I've been playing around with PHP for months now, playing around with string functions, loops, databases, recursion, and the like and I've never need any debugging tool more advanced from echo.

The kind of debugging tools you need or will find useful depend not only on the kind of language you are using, but the kind of problems you are solving and the style in which you program.

For instance, if you write bottom-up and do unit tests compulsively, you may rarely if ever see the need to step through the execution of a higher level function with a debugger. If you write top-down, however, it may be much more necessary since the exact behavior of your lower level units may be less certain to you.

I, for one, do most of my coding in a language with an interactive top-level -- Python -- wherein unit testing is easy and exception handling and stack backtraces work reasonably. I don't use the debugger; I unit-test my functions and classes from the interactive interpreter.

In languages without an interactive top-level, such as Perl or PHP, it may be useful to use a debugger to fake one. (You can do this in Perl by executing "perl -de 42", for instance.) It's not quite as useful as a real one, as found in Python or Lisp, but it does help.

Re:Does PHP need a good debugger?

[delta407]

Really, I've been playing around with PHP for months now, playing around with string functions, loops, databases, recursion, and the like and I've never need any debugging tool more advanced from echo.

Really? I've been writing a real-world application in PHP. I have created a device-independent output layer capable of writing XHTML, PDF, WML, and more with no extra coding, a flexible authentication system, a database-independent backend (far more nifty than it sounds), a module system that allows exporting individual pieces of functionality (including dependencies), a navigation system that's fully integrated with permissions, and lots of other things that come together to make a web application. Plus, I've written enough UI code to let a private high school do all of their functions (attendance, grading, transcripts, scheduling), and print all the reports they need (honor rolls, transcripts, attendance summaries, etc.). Total, this project has taken me seven months so far using my spare time, and I have written over 18,000 lines of PHP in this one application.

Guess what I use for debugging? I wrote a special error handler. Whenever an error occurs (except not parse errors), the error handler displays the snippet of code that it happened in -- complete with line numbers, syntax highlighting, and mouse-overs on the local variables that show their contents -- inside of a little box that I can open and close with a click. Plus, I can invoke this whenever I need, via the trigger_error() function.

Guess what made me write that error handler? echo ""` wasn't enough. When dealing with larger applications, you need to be able to look at what conditions prompted a failure, and a "print" is less than helpful. Honestly, even a dump of the offending code with the appropriate values inlaid isn't always enough; I would really like a backtrace, but I have to wait for PHP5.

<plug> If you want to develop something with my framework, hop on over to the website, grab it out of CVS, join the mailing list, and we'll be in touch. </plug>

It needs updating

[Ian.Waring]

I agree that the book is a good one (and I built my site after reading it). However, it reflects life at the dawn of PHP 4.0, and several things (particularly on PHP now shutting off globals by default, and changes on session control) now lead the user into some frustrating debugging sessions under 4.2.x onwards. At least until the PHP newsgroups and some of the more modern PHP books come to the rescue. I'd add "PHP Cookbook" (O'Reilly), "PHP Developers Cookbook" (SAMS) and "Web Database Applications with PHP and MySQL" (O'Reilly) alongside this book as good supplements to the more dated Welling/Thomson work. At least until they update it...

Re:It needs updating

[skribble]

I posted this here as a seperate post, but the Second Edition of this book (PHP and MySQL Web Development) will be showing up in bookstores around mid-February.

The 2nd edition has been updated to include PHP stuff that was unavailable or unclear in the first edition (register_globals, PEAR, XML, ...)

Read it on Safari without buying the paper version

[linuxbaby]

O'Reilly has a great service called Safari where you can read the entire book, searchable and everything, on their website.

Very handy for cut-and-pasting long chunks of code without having to retype it while reading the page.

Here's the link to read PHP and MySQL Web Development as reviewed here.

details details details...

[sunryder]

I used this book as a secondary reference for a Database course a couple of years ago, and then later for a reference on developing an online MessageBoard using PHP.

The book is pretty good, but tends to gloss over some of the more technical issues of PHP. In addition, the book tries to cover so much that there are a few parts that are missing some of the more complex details. For example, the section on PHP Session Management was a little too brief for my liking, and ended up being supplemented with material from http://www.php.net

These were are fairly minor issues and the only really *serious* issue I had with the book was the section on MySQL installation. It made the installation look so simple and straightforward, when in fact it was not. I attempted installing MySQL on several different boxes under both Mandrake and Redhat. In the end, the MySQL server was installed on a secondary machine under FreeBSD, where it installed without a hitch.

IIRC, this book covers PHP 4.0.

[Dthoma]

And so it's very out of date. This may go without saying, but PHP has had a lot of improvements and general tweaks made from then. Some of these tweaks may prove frustrating.

For example, in php.ini register_globals is now set to 'Off' by default (from 4.2 onwards) instead of 'On' and if the examples in the book assume that it is turned 'On' it means that the code samples in the book will cease to work. (For example, if the book uses '$subject' as opposed to '$_POST["subject"]' they could be in for it.)

Even assuming that the book doesn't assume that register_globals is on, there's another problem. Being of version 4.0, it won't use the get and post array variables $_GET and $_POST but rather the deprecated $HTTP_GET_VARS and $HTTP_POST_VARS.

There are other slight differences. For example, PHP 4.0 doesn't have the functions require_once and include_once, which are useful for making sure you don't accidentally include a file more than once (brilliant for avoiding function redeclaration errors) and the output buffering could be messed up by an incorrect setting in the php.ini file (implicit_flush, if you're wondering).

Plus it doesn't have useful string functions like strcoll and vsprintf).

Re:IIRC, this book covers PHP 4.0.

[__past__]

This is not a flaw of the book, but of it's topic. Granted, usually there are good reasons for the incompatible changes beween PHP releases, but it would be nice if the PHP developers could just take some time and try to think about things before they implement it.

It is nearly impossible to develop a portable PHP application. You never know what features are available in the installation a client uses. I want a stable development platform dammit, if I'd been looking for an mediocre ad-hoc syntax to access a huge and useful, but ever-changing and frequently buggy library, I'd use VB.

It Worked Great For Me

[Dr. Wu]

And I've been programming since the Pet/Apple ][/Atari days.

I wanted to make some changes to my website last year to take advantage of a MySQL database. While the O'Reilly Reference at the time got the database configured fine, it was more of an issue of getting the database tied into the website.

I picked up this book and within four hours it was up and running, and coded near-perfectly on the first run (there were some minor tweaks that need to be made for format).

While I agree that there are some great resources for PHP and MYSQL on the web, it doesn't exactly lend itself to armchair (or bathroom) reading. The other problem with the web is that I've found it hard to find step-by-step tutorials, versus code that focuses on a specific command or feature. Once you're familiar with a language, those resources are excellent. But when you're just starting to dabble, it's good to have a reference that takes you step-by-step through the process (even if you end up only skimming 75% of it).

I think the best testimony I can give for this book, is that after using it to get my site up, I lent it to one of the web programmers at the office (and let's just say that my company is a well-recognized name in the computer industry).

I haven't seen the book for six months.

Dr. Wu

Re:The Superiority of PHP over Perl

[kalos]

• Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Perl though.
• Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl! Its as though it was written in assembly, Perl requires that much rewriting.
• Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice) its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Perl lacks a graphics library of any kind.

I'll just use 3 of your reasons for now. Perl's DBI supports every database I've ever encountered, from the aforementioned MySQL to Oracle to Cache. Sorry, but no points there.

Other than any odd system calls where I shell out the only line of code I ever need change when moving from Linux to a Windows server (note I said Windows and not IIS.. the webserver is irrelevant) is the first line (the shebang). This is considerably easier when everything is a module but my earlier work requires less than a minute to update as well.

Perl has ImageMagick for graphics manipulation. Available in most flavors I've had great success with it in many areas. I was looking for an image gallery script and saw millions of php ones that were horrid and decided to write my own. Took less than 15 minutes to get everything downloaded and installed and a few more to write the scripts.

This isn't meant as a flame but your priase of php seems more likely to be a lack of understanding of Perl or just laziness.

why php vs. perl?

[b17bmbr]

i have been working with perl for a few years. so, a ocuple of months ago, i deccided to venture into php. plus, my school district just installed php onto their IIS (long story, freakin morons...) server. so, since i won't touch asp (whatever bastardized incarnation m$ decides this week) i figured i'd convert alot of our site to php. it has been for the most part fairly easy. but i still use alot of perl. especially for the flat file database stuff (since they won't give us even mysql).

here's what i discovered:

• learning php was fairly quick, very similar to perl syntax
• perl by a mile on regex. especially the default variable kind. php needs @_ and $_ in a big way. or am i missing something? shorter syntax, easier, at least for me.
• list() is a nice command, but i'll take @_=split(/:/$_/) any time.
• php is the SSI that perl could have been.
• 
  my point is this. i use perl to process much on the back end, maybe just 'cause i am so familiar. now, i simply save all my .html as .php. i don't see php as a perl replacement, but rather two complementary technologies. by themselves each is very powerful. but don't let this dissolve into a damn war over which language. use both. my $.02.

Re:why php vs. perl?

[jeremyacole]

I think you are missing something. How about:

$array = split(":", $blah);

or even

$array = preg_split('/:/', $blah);

The confusion is only that PHP uses $ for arrays as well as scalars. I.e., you don't have to use list() and name a bunch of variables on the left hand side.

Two Things

[ziriyab]

1. Amazon has it cheaper than BN by $5.00. And they have free shipping (vs. $4.00 min for BN)
2. The second edition of the same book is coming in about 3 weeks (Feb 13), so you may want to wait for that.

Re:Two Things

[CanSpice]

Yeah, but Amazon is eeeeevil and patent-hungry and BN is the white knight of buying books online!

About php.net

[Fulkkari]

I have never had any problems with php, because of the excellent, (almost?) clearly written documentation.

However what have suprised me on local php developer forums is that people completely new to any kind of programming find the site very technical and difficult to understand. Therefore will they often seek for alternative resources, like books or websites.

As you mentioned the free php projects, I have to say that I don't think that you can get very much out of those. I find it much better to look at small snippets than large projects, because it's much easier to understand. Especially for beginners.

Things the World Doesn't Need More of:

[ignatzMouse]

1. Cars
2. People
3. Books on using MySQL with PHP

Great book

[fbg111]

I was a noob PHP programmer several months ago. With this book combined with the downloadable HTML references at php.org and mysql.net, I learned it in no time. This book makes a great supplement to the official references b/c it provides a plethora of examples that demonstrate how to do certain techniques that are not always readily apparent.

Why I Chose PHP Over Perl

[egg troll]

Recently I've had a chance to do some web design with PHP. Previously I'd used Perl because I'd heard from many people that Perl was the end all and be all of scripting languages for the web. Imagine my suprise to discover that PHP was vastly superior! I know this is a bold statement, but I have solid arguements to support it.

Before I begin, let me just clarify something. I'm not arguing that PHP is better than Perl in all cases. There is certainly still a use
for Perl. Also, PHP isn't perfect but it does manage to fix many of the shortcomings I've had with Perl. Here are a few of the things I've
noticed about PHP. Finally, I'm not the most talented Perl programmer out there. I generally prefer to use the vastly superior Python, but
can use Perl if I have to.

* Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable
website up within 24 hours of reading the basics of PHP. Learning Perl took me weeks and I'm still not even as good with it as I am with PHP.
I would definitely not recommend anyone new to programming begin with Perl.

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.

* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Perl though.

* Speed. PHP is one of the fastest languages I've ever used. While it won't be replacing assembly or C, its definitely faster than Perl in almost every case, particularly in regex which has long been Perl's strongest point. I'm sure there are cases where Perl is equal to PHP, but I can't think of any at the moment.

* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it
run without having to change a single line of code. Try doing this with Perl! Its as though it was written in assembly, Perl requires that much rewriting.

* Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice)
its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Perl lacks a graphics library of any kind.

* Data Structures. Under PHP you can create any type of datastructure you need: Linked lists, binary trees, hash tables, queues, inverse
Reiser-biased recursion trees, etc. Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used. Because of this, PHP can support complex data structures.

Again this is just my experience. I don't mean to offend any Perl coders because Perl was an excellent language. However, in most cases it may behoove one to write the back end in PHP instead of Perl.

Thank you and God bless,

Egg Troll

Re:Different publisher.

[skribble]

Safari is a cooperative venture between O'Reilly and Pearson (which includes Sams). Safari really isn't O'Reilly's alone (though they do seem to do a better job of advertising it), and this book is available there.

Postgres?

[Micah]

Seems like there's tons of books on PHP and MySQL. Not to troll, but why doesn't someone release a book on PHP and PostgreSQL? It really is a better database, and does things in a somewhat more standardized way than MySQL.

Not that I would need such a book (since I already know the combo fairly well), but I'd like to be able to recommend PG to people over MySQL, and some would find a book like this useful.

Re:Postgres?

[axxackall]

As usually let's use s/my/pg/g :)

Seriously, have you tried PHPpgAdmin?

Features include:

• create and drop databases
• create, copy, drop and alter tables/views/sequences/functions/indicies/triggers
• edit and add fields (to the extent Postgres allows)
• execute any SQL-statement, even batch-queries
• manage primary and unique keys
• create and read dumps of tables
• administer one single database
• administer multiple servers
• administer postgres users and groups

Requirements: PHP 3.x+ (4+ suggested), PostgreSQL 7+, PHP enabled web server, Web Browser that supports frames and Javascript.

Important: New Edition of This book...

[skribble]

FYI a new Edition of this book which has been updated to include PEAR stuff, XML stuff, and various minor fixes will be in a book store near you around mid-February.

Some wrong fundamental facts

[leandrod]

MySQL is not a database. A database is a collection of data.

MySQL is not a full DBMS either, because it leaves things like transaction control to the application unless you take some extra steps (InnoDB).

MySQL is not relational, SQL violating several relational prescriptions and proscriptions and MySQL not even raising to SQL's already faulty levels.

Re:Some wrong fundamental facts

[axxackall]

Transaction management is not necessarily a prerequisite for "database" (DBMS). There is no cononical definition of "database" (DBMS).

Dr. E.F. Codd, a then IBM researcher, gave us both a canonical definition of RDBMS and rules explaining why transactional management is essential. Read it here.

Citing from the link, Rule 5: Comprehensive Data Sublanguage Rule: The database must support at least one clearly defined language that includes functionality for data definition, data manipulation, data integrity, and database transaction control. All commercial relational databases use forms of the standard SQL (Structured Query Language) as their supported comprehensive language.

MySQL is failed to be RDBMS. It still helps to manage data, somehow. But the way it pretends to be RDBMS is confusing many uneducated users and thus MySQL should be considered as a very bad phenomena in software industry.

Debugger?

[leed_25]

Total-noob> but I'm going to
Total-noob> go out on a limb here and say
Total-noob> that PHP doesn't need a
Total-noob> debugger

That sounds like something that a sales 'droid
said to my manager concerning a 4GL back in the
early '90s. My manager bought it. I have to
admit that, in the beginning, I was taken in, too;
but in the end this turned out to be an instance
of wishful thinking.

We tried to develop a modest user interface to
track the flow of materiel through a shipyard in
this 4GL. Of course, the implementation tuned out
to be much more intricate in the real world than
it had seemed to be in the 'blue sky' concept and
planning meetings.

End result: the 4GL code was almost impossible to
maintain. Eventually the project failed --for a
combination of reasons, to be fair. Here is a
king of maxim that I took away from it though:

Every line of code that is ever written will have
to be

1-debugged
2-maintained

Re:Why PHP rather than Perl?

[eddy the lip]

This isn't a troll but a real answer. Almost nothing.

Perl is more concise, has a superior collection of modules, is mature and has a more planned feel (for example, the whole register globals thing, or the changing of global array names in PHP are evidence of this). These things make perl eaiser and mroe productive to work with.

Other people (not me ;) ) like PHP because they say it has a lower barrier to entry so that less experienced developers can get up to speed faster. There's usually some comment about readability, but I think that's a bit of a red herring. Using Mason or Ax Kit or (insert templating system here) in perl will get you that much beloved separation of code and presentation that PHP tries so hard to discourage.

And after all that, I use PHP almost exclusively now. The biggest reason is deployment. I work on sites on numerous servers, and I never know where things will live. It got to be too much of a headache making sure the appropriate perl modules (eg, DBI) would be available. My biggest wish for Perl 6 isn't easier to read regexes, it's some kind of SDK system, where sysadmins can install perl with the Web Development SDK, or the what have you.

sigh. I miss perl.

How to make money on slashdot

[Black Perl]

How to make money on slashdot:

1. Insert your referral ID into amazon links
2. Profit!

Re:Why PHP rather than Perl?

[b17bmbr]

rather than the pissing match about perl has this, php that, first, see my earlier post about why php vs. perl

it's like this. a php page is simply a .html with a .php extension. if you never added on line of php code, and simply changed every .html link to .php, you'd not notice a thing. however, and i'm hardly some php guru, but you can do things like this: (forget all the DB suff, 'cause i do this with the homework pages for my school's website)

yo have a file, let's call it homework.hw ( a simple text file). i want to put the data on the page. now if i use perl, i have to call a cgi, and have a bunch of prints and maybe a bunch of heredocs, etc. then i have to basically do: open FILE, "homework.hw";while<FILE>;print; okay fine. but, in .php file, which is simply the exact same .html file, i simply use: <?php include "homework.hw";?> and viola. and of course, i use a perl/cgi form to create the homework.hw file. now, you can also create a link to the .php like this:

a href=index.php?teacher=smith

anf then the php looks like this:

<?php
include "$_GET[teahcer].hw";
?>

bottom line, use what your comfortable with. they are not competing. it's just taht php has some really useful aspects. not to satrt a flame war, but think of it as php->client-side, perl->server-side.

as i'm in the process of overhauling our school's site, what i like about it is the plugable nature of it. i create a series of modules, and include the in or not. also call them from GET or not. for instance:

to include a poll, simply do

<?php
if($_GET[poll]=="yes"){include "poll.php";}
?>

and the link looks like this:

a href="index.php?poll=yes&.......

so, my template is actually a single table, with 3 columns. anyways, it is a powerful tool.