PHP and MySQL Web Development 223
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.
online user comments on (Score:2, Informative)
Re:online user comments on (Score:5, Insightful)
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 [mysql.com]'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 [php.net]'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 [phpbuilder.com] than I have from the actual PHP/MySQL sites...
Re:online user comments on (Score:2)
S
Maybe the PHP and MySQL projects should... (Score:2)
I'm thinking of doing this myself, BTW - pumping all the PHP docs into a db for my own use - maybe the Perl and Java docs too for a single nice web search..
Re:online user comments on (Score:2)
Excellent Book (Score:5, Informative)
Apache Fun (Score:5, Funny)
-Mark
Old News (Score:3, Informative)
Re:Old News (Score:2)
You could look at the review as being out of date, as this book was published 2 years ago, but it would be better to think of it as being 2 weeks early, as the second edition is due out soon.
Here [amazon.com] is the old edition.
Here [amazon.com] is the new one.
If you want to build your own URL at a non-patenting bookstore, the ISBNs are 0672317842 (1st ed) and 067232525X (2nd ed).
Book comes with Linux (Score:1)
I Have This Book (Score:5, Interesting)
Fundamentals of Database Design [amazon.com] is a great book for learning about normalization of a database into any of the many forms.
MySQL [amazon.com] 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 (Score:4, Interesting)
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?
It Worked Great For Me (Score:4, Informative)
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:Target market (Score:2, Interesting)
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 (Score:2, Informative)
Brandon
www.php.net (Score:5, Informative)
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.
About php.net (Score:2, Insightful)
I have never had any problems with php, because of the excellent, (almost?) clearly written documentation [php.net].
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.
Re:www.php.net (Score:4, Insightful)
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
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.. (Score:3, Interesting)
Phpp (Score:2, Interesting)
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!
Re:Phpp (Score:2)
Why would a younger person being on the cutting edge of a relatively young language be considered not having their heart in the game, but an older one considered dumb for not "getting it" early on?
Realize that I'm at the upper end of the 30-year-old cutoff, and have a respectable understanding of Perl, PHP, and C...
Re:Phpp (Score:2)
A few examples:
Parse [cpan.org] and create [cpan.org] binary Excel files, even on Unix?
Automate [cpan.org] your smart home?
Configure a linux packet-filtering firewall [cpan.org]?
Monitor [cpan.org] SNMP devices across the enterprise?
Perform [cpan.org] various [cpan.org] System Administration [cpan.org] tasks? [cpan.org]
Program using the Win32 API [cpan.org]?
Write for extra speed? [cpan.org]
Write native GUI apps in windows [cpan.org] or unix/linux [cpan.org]?
There are over 4000 other reasons in the module repository known as CPAN [cpan.org].
I use several languages, but when I want to be productive, I turn to Perl because of CPAN. Generally, I have 80% of my code nicely abstracted in object-oriented modules. (Note to OO purists: bugger off, we're comparing to PHP not Scheme or Eiffel or whatever)
Re:Phpp (Score:2)
Write modules in C [cpan.org] for extra speed?
Re:Phpp (Score:2)
Sure, you can do all that in Perl, but only because someone has bothered to write the appropriate CPAN modules for you. That's not the same as saying you can't do those things in PHP.
As PEAR and PECL [php.net] (PHP's answer to CPAN) comes into it's own, I suspect you will see a lot of that functionality get ported over to PHP. Heck, some of what you mention has already been done.
But to say that PHP is not capable of doing any of those tasks is disingenuous.
Re:Phpp (Score:2)
Sure, you can do all that in Perl, but only because someone has bothered to write the appropriate CPAN modules for you. That's not the same as saying you can't do those things in PHP.
Ah, but that's my point. What is it you think I like about Perl? The syntax? Um, no. It's the sheer productivity from having a huge, exhaustive list of modules available.
If PHP or Python had something equivalent to CPAN, I'd probably switch. But doggone it, I'm addicted to being mega-productive.
SUEXEC. (Score:2)
I was always very pro-Perl, but I find myself using PHP for just about all web scripting now. I still use Perl for command-line stuff though, as I just know it better I guess. However, unless I've missed something, the biggest problem I have with PHP is that you can't run it through suexec (I understand why), so all PHP scripts run as the web server UID. This has often lead to me using a mixture of Perl+PHP (usually Perl scripts running via a cron-job).
I only use Apache1.3x though, since Apache2+PHP is pretty dire at the moment - so maybe they'll allow some equiv of suexec when Apache2 is ready for use...
Not ready for prime time (Score:3, Interesting)
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 (Score:2, Informative)
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
I believe there was a slashdot article last month which mentioned this also. Very impressive.
Re:Not ready for prime time (Score:4, Insightful)
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 (Score:2)
<flamebait>Well, my experience is that MySQL barely qualifies as a "real database" anyhow.</flamebait>
But, seriously, if you're using MySQL in read-only mode, then either you're not using a database, or our definition of database is very different. But in my experience MySQL is a reasonably stable "network filesystem with a psuedo-SQL interface." We've had servers here that have only gone down once in two years, and only then because we had to shut them down to change co-los.
On low and mid-range hardware (i.e., not on a $50,000 cluster), my experience is that MySQL is as stable as Oracle and MS SQL. When the database becomes innaccessible to the network, it's rarely because of problems with the database software.
Re:Not ready for prime time (Score:2)
Frankly, I'm not suprised that you had problems with MySQL. Like all databases, it may be brittle. However, in my experience, ALL databases may be brittle. I've never met ANY database server that couldn't be taken down by a configuration mistake or a misbehaving application.
But serving out small read-only databases inexpensively and reliably is one of MySQL's great strengths -- in fact, its only strength in my opinion. Better uptimes can be acheived, but only through the correct application of large dollars to many points on your server infrastructure.
I would be interested in hearing which database you've changed to which you've found more reliable for small read-only databases than MySQL, and what Operating System you're running both on. I'd also be interested in knowing what kind of performance difference you've seen -- have you had to buy additional servers, or can you get by with fewer now? I'm guessing you have a fairly high-performance application if you're using multiple DB servers, and benchmarking is important to you. Last, I'd be interested in knowing how much you've spent on Licensing, if applicable.
Re:Not ready for prime time (Score:2, Interesting)
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 (Score:3, Informative)
It needs updating (Score:5, Informative)
Re:It needs updating (Score:2, Informative)
The 2nd edition has been updated to include PHP stuff that was unavailable or unclear in the first edition (register_globals, PEAR, XML,
"up and running under both Linux and Windows" (Score:2)
Read it on Safari without buying the paper version (Score:5, Informative)
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 [oreilly.com] as reviewed here.
Different publisher. (Score:2)
But to get this comment back on topic, the review is about a Sams book, not the O'Reilly book on the same topic.
Picky, picky ,picky.
Re:Different publisher. (Score:2, Informative)
Re:Read it on Safari without buying the paper vers (Score:2)
details details details... (Score:4, Informative)
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 [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. (Score:5, Interesting)
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. (Score:4, Insightful)
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.
why php vs. perl? (Score:5, Interesting)
here's what i discovered:
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
Re:why php vs. perl? (Score:2)
Why didn't you just carry on using perl? You can use perl with iis just fine [activestate.com].
Re:why php vs. perl? (Score:2)
Re:why php vs. perl? (Score:2, Informative)
$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 (Score:5, Informative)
2. The second edition [amazon.com] of the same book is coming in about 3 weeks (Feb 13), so you may want to wait for that.
Re:Two Things (Score:2, Interesting)
How to make money on slashdot (Score:4, Insightful)
Re:How to make money on slashdot (Score:2)
Should he have used slashdot's refereal ID? The parent did put the effort into driving traffic and finding the books, with a direct link.
Re:How to make money on slashdot (Score:2)
2. Profit!
I apologize if that's what it looked like I was doing, but I don't even know how this referral thing works. I just copied and pasted the url after my search on amzon.
Thanks for the tip though. I'll make sure to use it next time :)
Things the World Doesn't Need More of: (Score:5, Funny)
2. People
3. Books on using MySQL with PHP
Why PHP rather than Perl? (Score:2)
Re:Why PHP rather than Perl? (Score:2)
With Perl, it's quite easy to write programs with constructs that will completely confuse a non-expert.
Re:Why PHP rather than Perl? (Score:2)
I use mod_perl with TT2, adding Class::DBI and a few other goodies, I absolutely love it. And yes, I would rather go back to the mind-numbing frustration of Weblogic (not saying anything about J2EE in general here, just Weblogic) than touch PHP... but then, we all have our preferences.
But no, I don't think the term "easier" applies here.
Re:Why PHP rather than Perl? (Score:5, Insightful)
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.
Re:Why PHP rather than Perl? (Score:2)
http://smarty.php.net/ [php.net]
PHP's trying to discourage templating?
Re:Why PHP rather than Perl? (Score:2)
I'm aware that there are templating solutions available for PHP, but the ordinary, default way to do things is to embed PHP code in HTML. This is the way most people learn it, and I'd wager the way most continue to use it, regardless of what templating tools become available. (I know it's the way most scripts I've been called in to fix do it). It's what the language was designed to do.
I'm not saying that you can't use templates with PHP, I'm saying that the design of the language encourages you to mix your code and HTML into one big soup. Using something like smarty adds a layer of complexity because it presents a different way of doing what the language was originally designed to do, just in a smarter, safer way. Using something like HTML::Template gives you a way of doing something that wasn't present in the language to begin with.
Which you prefer is to a large extent a matter of philosophy.
Re:Why PHP rather than Perl? (Score:2)
I've seen as many perl scripts embed HTML as I have PHP scripts. Blaming the language for bad programming practice on the part of the people using it is inane.
Re:Why PHP rather than Perl? (Score:2)
Y'know, I knew when I wrote that, that would be the response. You've missed my point.
Blaming a language for the shortcomings of it's programmers isn't a valid criticism, but pointing out that a language encourages certain kinds of bad behaviour is entirely relevant. C lends itself to memory leaks, Java lends itself to over-architecting (ok, arguable, but I'm trying to get an idea across here).
When PHP came around, it said "put <?php and ?> around your PHP and the output will get stuffed into your HTML." That was the whole idea. Templating systems came after to fix that idea. So, yes, the language does encourage mixing code and presentation. You don't have to do it, but it's a valid criticism.
Re:Why PHP rather than Perl? (Score:3, Informative)
it's like this. a php page is simply a
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
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.
Great book (Score:3, Interesting)
DB result caching (Score:2)
As it is now I end up writing a DB caching class for each app I write because I have to customize it so much to get any speed benefit (since you can't do any real caching). One method will not work on another app very well, depending on the number and types of queries.
IMO, Zend is holding PHP back. By crippling the language it forces you to buy the Zend Performance Suite to get good performance on an enterprise app. Unfortunately, this same crippling also makes making that enterprise app difficult and is why Java is better in the first place.
Why I Chose PHP Over Perl (Score:4, Interesting)
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:Why I Chose PHP Over Perl (Score:2)
Using Perl to do Web development is like using a hammer to build a house. I recommend using hammers when building houses, but it's not quite the be-all, end-all tool. Neither is PHP, VB, C#, Java, etc, etc.
There are Perl-based content management systems like bricolage that do a very nice job of abstracting away the routine tasks of Web development and providing some extra tools that are very useful.
I also suggest trying PHP as a templating language, while using Perl for the direct server manipulation (e.g. what mod_perl is really useful for) and for large, stand-alone back-end chunks.
A few of your points:
"Ease of use" -- You don't discuss ease of use. You discuss time to learn to program in the language. Different. It took me about 2 years to start thinking in Perl. Four years to feel that I understood it deeply enough to call myself an expert. Another 3 to realize I was wrong.
"The OO of PHP is excellent" -- Don't know anything about PHP's OO model. I do know that Perl doesn't have one. Perl 6 will introduce an OO model. Perl 5 allows you to roll your own. It does have some very nice tools for building an OO model, but that's not the same thing. I see this as a strength long-term (as it allowed Perl's OO usage to mature before being set in concrete), but it is a weakness in current usage.
"Outstanding database support" -- I don't like to say that Perl "is the best" at anything, but certainly in this department, you're way off the mark. Perl has amazingly well abstracted database support (DBI) for Oracle, Sybase, MySQL, MS SQL, PostgreSQL, DB2 and just about every other relational database known to man. It also has a very nice Web-based abstraction layer over DBI which allows you to hide some of the details in ways that Web developers tend to want.
"Data Structures" -- The mind boggles. Perl's complex data structures are sufficient to say the very least.
The rest is mostly misunderstanding and noise.
Yes, I realize the post I'm responding to was cut-and-paste from someone else's bad post by a self-professed troll, but I really don't like the idea that someone is going to see this and think it's true....
Postgres? (Score:3, Interesting)
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.
Postgres... and Python or Zope (Score:2)
Re:Postgres? (Score:2)
Re:Postgres? (Score:3, Informative)
Seriously, have you tried PHPpgAdmin [sourceforge.net]?
Features include:
- create and drop databases
- create, copy, drop and alter tables/views/sequences/functions/indicies/trigger
s
- 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.Re:Postgres? (Score:2)
Re:Postgres? (Score:2)
Important: New Edition of This book... (Score:3, Informative)
Some wrong fundamental facts (Score:2, Flamebait)
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 (Score:2)
Well, that means that Oracle or DB2 or MSSQL or PostGreSQL aren't databases if they have no data in them, and that my even asshole can be a database if I shove a small collection of data up it.
Say what you want about MySQL. Say it's not a real a DBMS, or impliments or follows SQL correctly. But it's still a god damn database in reality, and according to your own deffinition.
Oh yeah...Maybe some of us find it easler to start with something less complex. Maybe some of us don't need a fully-fledged DBMS either.
Sorry for feeding the troll.
Re:Some wrong fundamental facts (Score:2)
No, that means that a database is not a DBMS, and that a DBMS is not a database. See, a DBMS is a database management system, therefore it cannot be the thing it was created to manage. Similarly, data does not manage itself, but needs a DBMS (or a SysAdmin, operator or whatever else) to do that.
According to my definition it tries to be a DBMS, but fails for requiring too much of users and programmers. And it fails to be a SQL system too. But it sure can be used to suboptimally access a database.
Re:Some wrong fundamental facts (Score:2)
Ah, slight missunderstanding of deffinitions. In that case, MySQL must also be a DBMS. If it's not, I'd like you to prove me wrong since it's does infact--manage my data for me.
You could prove to me that it's a very basic or not very good DBMS. But not that it isn't a DBMS at all.
According to my definition it tries to be a DBMS, but fails for requiring too much of users and programmers. And it fails to be a SQL system too. But it sure can be used to suboptimally access a database.
How is requiring less requiring to much? Is this some kind of doublethink? I had a quick look over a begginers guide to Oracle and PHP, the amount of code for a connection or query was more complicated than MySQL. Now if the application doesn't need anything more complex than MySQL. What the point in going with anything else?
Sure, it isn't a real SQL DBMS either. But it still uses a lot of it's language--It supports a subset of MySQL. And like I said before, if that all that's needed, why bother with something else?
MySQL suits my current projects just fine. And if I ever find I need something more powerfull, then I'll use that.
Re:Some wrong fundamental facts (Score:2)
I would say fundamental, not slight
You have to do the integrity control, it doesn't yet. It is beginning to with InnoDB, but in a non-integrated, incomplete manner that needs an extra mile from you. So you can say it's not so good as it could be, but I would say it's not the real thing at all. Admittedly, no SQL flavour is or can be perfect, and no implementation of SQL is complete, but there are file access libraries, there are DBMSs, and things in between. MySQL is in between as yet.
Being scalable, generic, and declarative. MySQL may require less to start, but it sure requires more to develop and to scale.
If one starts with MySQL, eventually he will discover he needs something better. Then he will have to migrate, and in addition to the migration pain itself he will discover in horror that he could have done in a few declarative SQL integrity constraint lines what took lots of complex, error-prone procedural applicative code when using MySQL.
Now Oracle and PHP is not a good combination. PHP is not good with databases at all. And Oracle is know to be too complex and not conformant to anything but SQL Entry Level. But at least some of Oracle's complexity comes from it being scalable: you can connect to any account in any instance, but you never need more than a username/password@instance once your tnsnames.ora is set.
Because something else will require less coding and help you preserve your data integrity better, as well as scaling better.
Re:Some wrong fundamental facts (Score:3, Informative)
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 [itworld.com].
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.
Re:Some wrong fundamental facts (Score:2)
You can never scale, nor even be sure of your data integrity, without transaction. Fact. Period. If you do not understand that, you do not understand data. You might still manage to get some thing done, but with tremendous inefficiency, risk and limitations.
Re:Some wrong fundamental facts (Score:2)
One can argue that only a relational system can be a better DBMS, but sure there were and are non-relational DBMSs, for example SQL.
Yet nowadays data integrity is inherent part of a DBMS. Same as with OSs: initial ones would be little but loaders nowadays; today if someone launched a CP/M thingie it would never be accepted as a OS. The threshold shifts.
And? It does not make MySQL any better, same as the wider availability of MS-WXP does not make it any better.
Agreed, and I already told them so. I even tried to start a SourceForge project, but my time is not yet ripe. Anyway there is Alphora Dataphor already, which is not free in any meaning but has a free, feature-full demo available. And anyone can implement either Tutorial D, or D4, or any other valid D.
Re:Some wrong fundamental facts (Score:2)
Transactions are only supported in the optional table type InnoDB. Now, even the notion of an optional table type is unnecessary complexity: transactions must be the default behaviour. Not even PostgreSQL gets this as well as I would hope, but MySQL really is a mess. Now InnoDB is an amazing piece of software, but it needs to be the default, standard, do-not-even-think-about-it thing to do.
What about ISO SQL? Take anything from SQL 89 Entry Level, MySQL compliance is as bad as Oracle and even worse, without its robustness.
No, I mean that the language is not SQL, and there is not a clear direction about if and when it will reach compliance, and with which caveats.
Re:Some wrong fundamental facts (Score:2)
The question is not how well-written are the statements. But how well modelled is the database. A normalised database enables users to do much more intelligent queries. And most people code well in the sense that the statements are not ugly, but very bad indeed in failing to make use of the integrity constraints available in SQL, thus duplicating effort, wasting resources and risking data.
Pointers and NULLs, or GROUP BY sure enough should never had been included. But integrity constraint and transactions are hardly obscure, but truly essential. If you do not see that, you never understood SQL.
I agree they are a hack, and discount MySQL also on that basis. But all I heard of InnoDB is that it is an amazing piece of software, and that is is badly integrated but this impacts development (never forget specifying the table type), not operation. Why do you think it cannot be used in production?
First, let me admit that I just checked and MySQL does now have a decent basic SQL type system. But reading their documentation really drove me nuts: they still think of tables as the basic construct, and generally do not grok databases except as as programming utility. Treating transactions as optional... hah!
Not only that, but their comparision with PostgreSQL is really biased, more than is granted in vendor-written material. If they cannot be a little bit fairer, they should refrain from speech.
Now, I do not think PostgreSQL to be bloated. Evidence to the contrary welcome.
And if there is something that PostgreSQL does right, is in an extensible type system. MySQL does not plan to implement the single redeeming SQL feature!
Debugger? (Score:2, Insightful)
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
Does PHP need a good debugger? (Score:5, Insightful)
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? (Score:4, Insightful)
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? (Score:2)
That doesn't bother you? I do php by day and Python by night and with Python's traceback output I never have to puzzle over a problem for more than a few minutes.
Re:Does PHP need a good debugger? (Score:4, Informative)
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 [lissard.org], grab it out of CVS, join the mailing list, and we'll be in touch. </plug>
Re:Does PHP need a good debugger? (Score:2)
Re:Does PHP need a good debugger? (Score:2)
Again, it's just a matter of time until I modernize it. Though, I have to ask -- what are you using PHP for that isn't a web project?
A good debugger is always welcome. (Score:2)
Of course, having a debugger for PHP would be very useful, but I wouldn't consider it to be a very high priority, especially as someone else in this thread seems to have posted a link to a reasonable (though still alpha) PHP debugger prototype which works well.
Re:Does PHP need a good debugger? (Score:2)
Re:The Superiority of PHP over Perl (Score:3, Interesting)
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.
Re:The Superiority of PHP over Perl (Score:2)
Check out Gallery [sourceforge.net] - the best gallery app I've seen, period.
Move to Mod_perl (Score:2)
You don't need destructors in PHP (Score:2)
Re:Ok, I'll bite. (Score:2)
Doesn't it release resources upon each page completion?
Re:slashdotted slashdot? (Score:2, Offtopic)
I was initially going to link to this [pcworld.com] or this [newscientist.com] article, but the first included this memorable quote:
Mmmmmm... Soft, chewy center...
Re:slashdotted slashdot? (Score:2)
Re:slashdotted slashdot? (Score:2)
A lot of "write" operations changing the result returning by the same URL request (so caching is not a real help).
Few months ago I did the test comparing the overhead of Bugzilla when it's implemented with MySQL vs PostgreSQL (I have to choose between them for very weak hardware). PostgreSQL was keeping up much longer than MySQL on massive concurrent write-requests when increasing amount of concurrent users (actually concurrent test scripts) simultaniously publishing new bugs and new bug comments and changing bug status.
I wonder if Slashdot developers tried similar tests with their software between MySQL and PostgreSQL.