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...

Re:online user comments on

[Anonymous Coward]

the php comments are not moderated/proofread *every day*, but they are proofread periodically. take a look at them. you'll see things like *Editor's note: although this will work, it's not because of why you think it will* or whatever

Re:online user comments on

[Anonymous Coward]

Unless you want to do some real development- then you will use modperl or J2EE

Re:online user comments on

[TheTomcat]

PHP.net's comments are moderated and proofed. Many developers have access to this; I do.

S

Re:online user comments on

[c.collins.bml]

Beyond the comments, the "404" page pretty slick! It appears to try to find what you were looking for in the manual pages before telling you you made a mistake.

For example, you can go to http://www.php.net/date and it will take you to the date() function in the manual, even though http://www.php.net/date does not exist. This works for all of the functions, as far as I can tell.

Re:online user comments on

[christowang]

It's all relative. Where do you go on Microsoft's site to find help with MS SQL or ASP?

Re:online user comments on

[Frymaster]

for north americans who find www.php.net too slow, there is a faster one at: us2.php.net

Re:online user comments on

[espostor]

The MSDN portion of Microsoft's site has boatloads of references, examples, etc. I've rarely had a problem finding what I need reference-wise there. Like here or here.

Or was the question rhetorical? Bah.

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.

The Superiority of PHP over Perl

[Anonymous Coward]

Hello Slashdot,

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 certain cases it may behoove one to write the back end in PHP instead of Perl.

Re:The Superiority of PHP over Perl

[Anonymous Coward]

I work for a major Fortune 500 company and we were planning to move all our web enabled SMB relational databases to Apache and Mod_Pearl, but thanks to this /. post we are now planning to migrate our aging Novell setup to IIS+Perl. Thank you /.!!

Re:The Superiority of PHP over Perl

[Anonymous Coward]

So close, yet so far.

You got a bit too blatant in saying what perl can't do. Any newbie could have seen it was a troll after the Data Structures section.

Good try, but you need to be a bit more subtle -- bash perl for being obscure and hard to read (write-once, etc), not saying it can't do something that even grandma knows it can (i.e. data structures).

I look forward to v1.1, good man!

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.

Re:The Superiority of PHP over Perl

[Ringlord]

PHP was created with webpages in mind. Perl was not. Where I work we use PHP for all web development, and Perl for all the under the hood work of systems management, messaging, etc.

While we could certainly have used Perl for web development, we found PHP a better tool for this.

Re:The Superiority of PHP over Perl

[Jack9]

ImageMagick is a third-party addon. That's not a valid point either, to be fair.

Re:The Superiority of PHP over Perl

[Anonymous Coward]

Nice troll. I am sure you will get some takers....

BTW. If you want people to think you have even a modicum of knowledge about programming don't:

1. suggest designing shoot-em ups in VB. Doom was never written in VB... While it is certainly possible that it had a vb wrapper for windows, the game itself is coded in nothing other than C or some other low level language, possibly assembler.

2. The OO of PHP is excellent--- is not true. While you can do some OO like things with it, it doesn't meet the qualifications for OO. Perl is much closer.
3. Perl seems limited to MySQL and PostgreSQL --
absolutely untrue. fire up a CPAN shell and do a search for DBD.
4. its definitely faster than Perl --
again, absolutely untrue. Maybe you are running perl in CGI mode and php as mod_php? Try testing *mod_perl* against mod_php, or php CGI against Perl CGI. There isn't much of a speed difference.

5. Portability. -- Try doing this with Perl --
Again, untrue. If you rely on unix libraries using perl, of course it won't work in windows. Same applies to PHP and both going from nt to *ix.

I port code all the time.

6. Graphics. PHP comes with a nice little graphics library --- Actually this may be true, but probably isn't. PHP uses either ImageMagick or GD, depending on what you want to use. Perl can too.

7. Data Structures. Under PHP you can create any type of datastructure you need --- Partially true. Fact is, you can create almost any datastructure in perl that you are inclined to. It is just a lot more painful in Perl.

As a programmer who switched from Perl to PHP, for web stuff, 3 years ago, I am not downing the language, I prefer it for web stuff, but we need to make sure we present factual arguments for PHP so as to not look as though we are inexperienced.

There are some things that Perl does better. PHP and Perl are both in my swiss army knife. My only preference is to use the right tool for the job.

L8,
AC

Re:The Superiority of PHP over Perl

[ceejayoz]

I was looking for an image gallery script and saw millions of php ones that were horrid and decided to write my own.

Check out Gallery - the best gallery app I've seen, period.

Re:The Superiority of PHP over Perl

[Anonymous Coward]

... You're both sort of wrong even when you're right, and the OP is just a troll. FYI PHP's "native" image manipulation is just boutell's libgd, and perl has a GD.pm to act in a similar fashion to the gd functions in php. PHP does not, at this time, support ImageMagick (and yes, ImageMagick and GD are different tools with different capabilities). So both languages use "third party addons" for graphics compositing and generation.

Re:The Superiority of PHP over Perl

[jfarrell1983]

PERL Supporst Oracle, so does PHP as well

Re:The Superiority of PHP over Perl

[TSN_RadiX]

True, true..

But some people (yours truly) learnt Perl as their first 'web' scripting language in Year10 at highschool.. and produced the backend scripts that now power this site: www.operation-scifi.com

although somewhat outdated now and not as effecient as the huge experience and knowledge I now have with PHP/mySQL it was still quite ground breaking for me to write my own Perl forum and member management routines at 16 years old..

I am very proud of it as it now boasts a system of 280+ members and in the vicinity of 16000 posts [see: http://operation-scifi.com/forum/info.php]

Well.. 'nuff said.

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.

Re:Old News

[Kool Moe]

Coward,
I appreciate posts like this cause I don't know PHP/MySQL - but would like to someday. It's reviews like this that help, and may push me to actually get started.
It's fun to be grounded. Get off that high horse.
KM

Re:Old News

[tangledweb]

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 is the old edition.

Here 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).

Re:Old News

[Anonymous Coward]

I agree, ferking ridiculous. slashdot is getting out of hand.

Re:Old News

[Anonymous Coward]

Hey Fool Moe,

If you want to learn PHP are you going to start with a two year old version? Posting a review of a book that came out two years ago, when there is a new version due out in a couple of weeks is a waste of time.

Book comes with Linux

[Alcohol Fueled]

Apparently, a distribution of Linux comes on the CD as well... Here is the book on linux.org

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.

Re:www.php.net

[telbij]

I think a hard-copy reference is always useful for beginners, regardless of the quality of on-line documentation. Existing open-source projects are a great way to see how things are done, but there you run into the problem of learning bad habits from poorly written/commented code.

Where books really fill in nicely is giving programmers a road map of how to develop their application to avoid common pitfalls. Of course, this all depends on the expertise of the author.

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!

Re:Phpp

[psychosis]

That saying is rather interesting - I've never heard it before. I don't really think that I agree with it, though, espescially as Smarty and PEAR start falling into wider use. PHP is really starting to come into its own.
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

[Black Perl]

what exactly what can you do with perl that you can't do with php???

A few examples:

Parse and create binary Excel files, even on Unix?

Automate your smart home?

Configure a linux packet-filtering firewall?

Monitor SNMP devices across the enterprise?

Perform various System Administration tasks?

Program using the Win32 API?

Write for extra speed?

Write native GUI apps in windows or unix/linux?

There are over 4000 other reasons in the module repository known as CPAN.

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

[Black Perl]

Slight typo above. The second-to-last bullet should read:

Write modules in C for extra speed?

Re:Phpp

[Greedo]

Your comment isn't entirely fair.

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'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

[Michael Ross]

...I find that phphome is amazing... www.phphome.net ?

Re:Phpp

[Anonymous Coward]

Parse and create binary Excel files, even on Unix?
Yes. And Flash and a few other things as well.

Automate your smart home?
No but that doesn't mean it can't.

Configure a linux packet-filtering firewall?
Ditto.

Monitor SNMP devices across the enterprise?
Yes, it has full SNMP support.

Perform various System Administration tasks?
Yes, it can exec anything you like, and it can run standalone (without Apache) like any shell tool.

Program using the Win32 API?
Yes, PHP/GTK.

Write for extra speed?
I guess?

Write native GUI apps in windows or unix/linux?
Yes, PHP/GTK.

It's just a language, like perl or anything else. It's what you do with it that matters.

Re:Phpp

[Black Perl]

Your comment isn't entirely fair.

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.

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.

Re:Not ready for prime time

[tuxlove]

Not quite sure what you're driving at with the "dozens of people" statement. We have a couple of people maintaining/developing the database for MySQL. And we build the database periodically on a single machine and replicate it on the front-line servers. It's not a complicated database, nor a complicated usage mode. And it's read-only. Such a simple setup shouldn't be so difficult to keep running, but MySQL craps out regularly.

Your mileage may vary, of course, but real databases generally don't behave like this.

Oh, and to the moderator who gave me a troll point: disagreeing with me is quite a different thing from me being a troll. Read the moderator guidelines.

Re:Not ready for prime time

[Anonymous Coward]

You were the one who claimed to have hundreds of servers running MySQL.

It's unlikely you're using multiple servers to access a single database instance -- although that's possible for databases like MS SQL and Oracle, I doubt MySQL does it yet. So, hundreds of servers means hundreds of seperate databases, minimum. Since each server may run multiple databases, you may even have thousands of databases.

The intellectual capital to compentently maintain hundreds or even thousands of seperate databases is pretty heavy. If you're not running into problems with "a couple of people maintaining the database", then you're either not maintaining your hundreds of databases compentently, or you're simply not maintaining hundreds of databases.

Re:Not ready for prime time

[bellings]

Your mileage may vary, of course, but real databases generally don't behave like this.

<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

[tuxlove]

You were the one who claimed to have hundreds of servers running MySQL.

Lots of servers does not equate to dozens of people or multiple databases. We have *one* database, and we replicate it to multiple MySQL servers. You certainly read a lot into my message, which mentioned only that we had multiple *servers*, and not what was on them or how they were configured.

Now, I have little doubt that some people have success with MySQL. But in our simple setup, a single, relatively small, read-only database propagated to multiple MySQL servers with local storage, we've experienced enough wierdness that I have to seriously question the suitability of the product.

The intellectual capital to compentently maintain hundreds or even thousands of seperate databases is pretty heavy.

Huh? You can (and must!) automate service architectures that require multiple identical servers. It generally does not require a whole lot of people to manage. Software and data pushes are automated, monitoring is automated, and so on. Just about all that's not automated is repairing broken machines, and that's greatly minimized by having clearly-defined procedures. But if you have lots-o-machines that conk out strangely and regularly, it can tax resources to keep things running smoothly. We take out MySQL, and things are much more smooth. That's all I'm saying.

Re:Not ready for prime time

[bellings]

So, you have one small database, which is running read only on a few dedicated servers running MySQL?

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

[tuxlove]

I believe the MySQL servers are FreeBSD, not 100% sure. If not, then Linux. Since our queries are well-defined and never ad-hoc, we access a simple (non-SQL) Berkeley DB database (www.sleepycat.com) directly from PHP. Licensing is cheap, but not free. We have a site license, and it cost about as much as one of our servers. So far it's quite fast and reliable. Don't know how much faster than MySQL it is, though I suspect it's measurable.

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?

[CmdrGravy]

I tend to agree that you don't *need* a good debugger for PHP because if you find yourself in the situation where it is impossible to debug your code then you really need to do some restructuring.

None the less though having a good debugger could quite often cut down that 30mins identifying problems using echo, var_dump etc to 1 or 2 minutes and I would certainly find that to be a great help.

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?

[SpamJunkie]

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

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?

[Anonymous Coward]

While I'm not too much of a good php-writer myself, I think most people who have used more then a few versions of PHP - preferably on different systems with different admins - will have found themselves in situations where incompatible variable naming between different versions (like $GLOBALS["from"] instead of $from) can kill hours of your time. Sure, you can find errors like this using echo's, but you can find errors in Java programs by looking at the byte-code with a hex-editor, and how many people are doing that?

A good debugger would be extremely helpfull to me!

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>

Re:Does PHP need a good debugger?

[aoeuid]

Thats not because of incompatible versions. Its a security consideration, configurable in the configuration file.

Re:Does PHP need a good debugger?

[Jack9]

I looked at the error routines. Very nice. I actually bookmarked your LISSARD CVS page so that I can check for updates and am working on using the code for my personal web project because it serves as a syntax and partial logic trap that I think is very well designed. Essentially these are echos though and apparently only tailored for a web project. If it figured out the globals and locals of the offending code it would probably qualify as a rudimentary debugger, rather than the pretty custom toy that it currently is. Of course, when all you have is PHP, you can only make PHPade.

Re:Does PHP need a good debugger?

[delta407]

If it figured out the globals and locals of the offending code it would probably qualify as a rudimentary debugger, rather than the pretty custom toy that it currently is.

It does figure out globals and locals. Mouseover the underlined variables; it works under Mozilla, Konqeror, and IE. Want a unit test? Stick the following into test.php:

<?php
require_once("errors.php");
function a($var1, $var2)
{
if ($var1 == 'abc')
trigger_error('Uh oh! ABC!', E_USER_ERROR);
}

a('abc', 4);

?>

Re:Does PHP need a good debugger?

[Jack9]

I stand corrected.

Re:Does PHP need a good debugger?

[delta407]

Oh, one more thing.

Essentially these are echos though and apparently only tailored for a web project.

True. I have not yet modified the error routines to support the object-oriented output layer, but once I do that, it will be able to report errors to anything the output layer can -- again, XHTML, PDF, WML, even ncurses if you felt like it. There are no 'echo' calls anywhere in LISSARD except for errors.php and the theme file, meaning that the presentation could be to a totally different medium (via a different theme file) and everything but the errors will use it.

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?

Re:Does PHP need a good debugger?

[Jack9]

While I use PHP for web development and oft abuse it when a small bash script would do as well, I specifically use PHP as a data presentation layer. There has yet to be a database PHP has had trouble with...as opposed to say Perl in 1999 when I had to RANDOMLY GUESS AT SYNTAX for 3 weeks to get a Perl DBI to work (Larry said to just guess at it till it worked, and I did).

I routinely get some application that exports to a specific format flat file and somebody wants it to be this or that. I either format the data to a different format or parse it into a DB. Outside of my normal job, this is a good 60% of all problems I'm contracted to solve. Yes Perl can do it. Yes Python could do it (most of the time). Yes lots of other languages can do it.

As an aside, I don't like support. I'm not a support guy and I loath customers after I completed a job to original specification. When I leave a job or finish a contract, I don't get called again because I train or provide someone who likes that stuff and is capable of maintaining it. PHP is very easy to teach and is honestly a very low-wage skill. PHP as a skill, is easy to find at universities in california which has contributed to my preference for it.

Re:Does PHP need a good debugger?

[Anonymous Coward]

Congratulations! You are the recipient of a once-in-a-lifetime event: the rare, but not theoretically impossible (??) Slashdot +6 score! :)

See your user page for more info:

IIRC, this book covers PHP 4.0. 05:19 PM January 27th, 2003 Replies:3 Score:5, Interesting
attached to PHP and MySQL Web Development
Does PHP need a good debugger? 05:01 PM January 27th, 2003 Replies:7 Score:6, Insightful
attached to PHP and MySQL Web Development
As an English person, I'd have to say... 10:48 PM January 25th, 2003 Score:2
attached to Journal Discussion: If you could....
Major.minor.maintenance 10:10 PM January 25th, 2003 Score:2

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, ...)

Re:It needs updating

[AShocka]

Are there any books that are up to date on these techniques, related to php 4.2 and greater? What are the best sites and references to avoid the short comings associated with older versions referenced in books?

"up and running under both Linux and Windows"

[burgburgburg]

Considering all the work that O'Reilly has already done with educating users on web serving on OS X with Apache, PHP and MySQL already, I'm surprised that they wouldn't even bring it up in a supposedly comprehensive beginner/intermediate book. Left hand/right hand, perhaps.

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.

Good book

[PhilipChapman]

I bought this book a few years ago. I found it very helpful as a beginner programmer. Unlike some books which just teach you the concepts, this book show you how to use them in real world applications. Alot of code you can basically reuse in your own projects. I reccomend the book to anyone who wants to learn how to use php and mysql together.

Remember a couple days ago.

[aerojad]

Just as long as people are taught to apply a 6 month old patch so their SQL isn't being pinged into oblivion :)

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.

next book review: Orwell's 1984

[dubiousmike]

PHP and MySQL Web Development

Luke Welling, Laura Thomson

Paperback, March 2001

How long does a book need to be out before it gets reviewed? Is it still viable after almost 2 years?

while this book is very good..

[mr_ody]

I feel it dosnt touch the configuation and running of a mysql database very well.. you get a few dabs of enlightenment here and there but really it should be the first thing every mysql+php developer should know and understand.. and so should have more leafs dedicated to it. still its a great book and I would part with it.

Re:Read it on Safari without buying the paper vers

[Fulkkari]

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

Great link indeed. Too bad you can only use the full version for 14 days free.

Still $14.99 / month isn't _so_ bad, if you really would use these...

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.

[Anonymous Coward]

There are other slight differences. For example, PHP 4.0 doesn't have the functions require_once and include_once

Erm, I think you'll find that it does.

Re:IIRC, this book covers PHP 4.0.

[messju]

and strcoll() is also available since 4.0.5

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.

Re:Great!

[Anonymous Coward]

I've not heard of PHP being slow before. I've been using it for 3.5 years and I've been very impressed by it's speed.

Gee, let's bitch about a free, lighting fast database that gives 95% of users what the need, but charges for a small, specialized add-on.

As for a debugger - how many PHP developers have a need for a debugger? There are some, you say? I agree, and for those folks they're hopefully using a decent templating engine like Smarty which includes a very slick debugging window.

Re:next book review: Orwell's 1984

[Alcohol Fueled]

Sure it is. It'll still be viable when it's reposted in a couple weeks. :)

Mildly OT: Get RedHat 8 for MySQL & PHP instal

[Anonymous Coward]

I know this is a shameless plug, but it really is flawless. Install MySQL, install PHP, then do a google search for the RPM which automatically integrates the too. Bada-boom, bada-bing.

PhP and database security papers

[Anonymous Coward]

www.cgisecurity.com/lib

You don't need destructors in PHP

[Ron Harwood]

Consider that each page is a mini-application... and before you would have to worry about needing a destructor... the application has completed... and all memory/resources are relased...

Re:You don't need destructors in PHP

[Anonymous Coward]

That assumes your using it for web page use and not as some stand alone script.

Re:You don't need destructors in PHP

[Jack9]

Hypertext Preprocessor - I dont think anyone is using PHP for pure scripting in critical applications yet. That would be silly. PHP is obviously not a finished language, so attacking the memory management of it's beta standalone scripting capability is rather innane and certainly not worth commenting any further about.

Re:You don't need destructors in PHP

[spankfish]

I dont think anyone is using PHP for pure scripting in critical applications yet. That would be silly.

You'd be wrong. Several of my clients are using a command-line php script of mine for dispatching mail. Why did I use PHP and not Perl? DBI.

Re:You don't need destructors in PHP

[Jack9]

Tell me you're kidding. Email is not critical in the sense that if an email fails, nobody is liable or legally responsible. I use PHP for automating mail jobs too, BECAUSE email is not critical. The emails I am referring to are formatted and sent using PHP and are something that has to get done (part of the job I was hired to do)...but do you honestly think I'd use a PHP script to do complex financials or to transmit credit card numbers. PHP can't even send data to printers reliably. I dont think the lack of destructors alone makes PHP unfit for serious business, but I dont think it's trustworthy yet either.

don't you hate it when people start their comment

[micromoog]

in the subject line

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

PHP online manual has poor comments?

[Dthoma]

1. I've always found that the comments are helpful marginalia which can point out obscure cases where PHP might fall over, an alternative function which will work better than the one you're looking up, etc.

and...

2. If the user notes bother you, you can download the entire manual in HTML as a BZ2 archive (it's about 830KB) from the PHP website.

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?

[X-Nc]

> i don't see php as a perl replacement, but rather two complementary technologies.

Bravo! Very well said.

I have never understood the need for some to view programming languages (or, indeed, any computer technology) from a zero-sum perspective. Programming languages are tools, each has it's strengths and weaknesses. Use the right one for the right job. Very often the best solution to a problem is to use more than one tool together. After all, you do not see carpenters having flame wars over whether a hammer or a screwdriver is better for building a house.

Re:why php vs. perl?

[JimDabell]

...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.

Why didn't you just carry on using perl? You can use perl with iis just fine.

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.

Re:why php vs. perl?

[jfarrell1983]

I have now been programming PHP for over a year, and while I used to do a lot of PERL i know find i use PHP always. The reason being is that to really get the full power of PERL requires loading new modules and configuring them. Whereas with PHP its all there by default of the compilation and all the configuration is located in one file that is easy to edit and display if needed. While I support PHP/Perl driven websites, I also look at the fact that Perl has been around for quite a long time, which to me suggests the main reason for its power, and that PHP (whos adaptation is un precedented) is even being considered with it is a huge achievment. While nowhere in the near future do I see PHP replacing PERL, I think someday it will happen. And thats my $.02 ;)

Re:why php vs. perl?

[b17bmbr]

i do use perl alot. a funny story about this is that when they decided to do their own hosting and switched servers, mid year i might add, they had no idea that they even installed perl. they didn't even know where it was!! i had to google to find out how to access it on iis. (of course, you can access perl from any folder, typical m$ functionality over security. plus, i discovered, accidentaly, perl operates at system level privelges, cgi can read/write anywhere!!) in fact one of the reasons is the lack of database access. it is their server!! so i had to put all the school news, homework, etc., etc., in flat databases. pita really. but anyways...i use perl for lots on the back end.

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!

Move to IIS

[Anonymous Coward]

And the shebang becomes irrelevant.

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.

Re:About php.net

[CmdrGravy]

I agree that small snippets are undoubtedly the best way to learn how to do specific things, e.g. make a search engine or send an e-mail. However I think there comes a point where you realise that you don't have to particulary bother to learn how to do these things until you need to use them. At that point you just find a sample to cut and paste and adapt to your needs. Where I think looking at the way other people have created their web site, CMS or whatever is helpful is to learn the best way to structure your entire PHP project. And indeed I think that learning these structures is probably the best way to ensure your ideas work out in practice. I think you can learn a lot just by looking at a few of the include scripts that the way they have chosen to design -whatever - is either very bad ( in which case you won't have a clue what is going on anywhere ) or very good. Learn from the good and avoid the bad.

Things the World Doesn't Need More of:

[ignatzMouse]

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

Re:next book review: Orwell's 1984

[lisam]

I don't know the book...if teh book is outdated, then the review shouldn't be posted now, but if tehbook is stil useful, why not?

This book is great

[Anonymous Coward]

A few months ago, I decided that I was going to add PHP to my resume. This book is great, even for those of us who have already programmed in other languages. This book is also a great reference for MySQL, and a lot of its conversion functions for dates and passwords.
The last couple chapters are about reinventing the wheel: writing a web forum and writing an email client. Even though there are many open source projects in these categories, the database design concepts behind the chapters is of great value.
I'd reccomend this book to anybody of ANY skill level in programming who wishes to learn PHP and MySQL. I haven't had my copy back for a few weeks now because so many of my friends in the comp sci department here want to borrow it.

Re:slashdotted slashdot?

[dcuny]

If anything, it's more likely caused by the SQL Slammer worm.

I was initially going to link to this or this article, but the first included this memorable quote:

We like to think of most corporations as hard candies with a soft chewy center," Rouland said.

Mmmmmm... Soft, chewy center...

Re:Great!

[buckminster]

The Zend Studio PHP debugger is not that bad. It's part of an integrated IDE which includes nice support for remote debugging.

Why PHP rather than Perl?

[isomeme]

I've never quite understood the attraction of PHP over Perl (using e.g. Mason or Template to get the templating capability). This isn't a troll, this is a real question. What does PHP do better or easier than Perl plus a templating engine?

Re:Why PHP rather than Perl?

[dismayed]

Lost overall cost to benefit... Server setup is a big part of it, if you don't have control over the server and the client is on a low budget then its usually easier to find a host supporting php.
At least thats what I've decided.

Re:Why PHP rather than Perl?

[Concerned Onlooker]

Coming from a beginner's standpoint, which I'd say the book is really geared toward, I can say that PHP is simply much, much easier to get going than Perl. I spent a few days (beginner, remember) installing the DBI and DBI::MySQL, trying to understand them and then actually getting a connection to MySQL.

On the other hand I tried the same project I had been working on in Perl with PHP and I was able to achieve the same results in about one afternoon. Just looking at the way a connection is made is a good example. All you do is

$conn=mysql_connect("localhost","username","pass word")

and you're there.

This is not Perl bashing. I like Perl quite a bit and use it for file management, html creation, etc. but if you're just starting out like I was it seems that PHP is the right tool for the job if you're trying to create a dynamic site based on interfacing with MySQL, or most other DBs I believe.

Re:Why PHP rather than Perl?

[SnatMandu]

Readibility. There might be more than one way to do it in PHP, but whichever way you pick, it'll be possible for me to read it. I can give my PHP programs to other, less experienced programmers, and they can figure out what's going on.

With Perl, it's quite easy to write programs with constructs that will completely confuse a non-expert.

Re:Why PHP rather than Perl?

[glwtta]

PHP has a reputation for being "easy", and I guess perl just isn't viewed as sexy by new web developers.

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?

[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.

Re:Why PHP rather than Perl?

[ceejayoz]

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.

http://smarty.php.net/

PHP's trying to discourage templating?

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.

Re:Why PHP rather than Perl?

[eddy the lip]

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?

[Bradley Batt]

IF the *.hw file is simply text you really shouldn't use include, but rather the file command.

For example, use
$html = implode ('', file ("$_GET[teahcer].hw"));
echo $html;

Include evalutates the file for PHP commands, so you could get some unintended results.

Also, from PHP's website: Note: As of PHP 4.3.0 you can use file_get_contents() to return the contents of a file as a string.

At least you didn't use include "$_GET[teahcer]";!!

Re:Why PHP rather than Perl?

[ceejayoz]

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.

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?

[eddy the lip]

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?

[Anonymous Coward]

Actually there is a system of separating content from code, in PHP. This is called Smarty and it's pretty good, it even automatically compiles templates into native PHP code each time the templates are updated (checking is done via the file's last modification time). Smarty has been around for quite a while and appears to be pretty popular.

Re:Why PHP rather than Perl?

[kubrick]

With Perl, it's quite easy to write programs with constructs that will completely confuse a non-expert.

I realise that this is one of those religious issues... but isn't that a problem with the Perl programmer writing the confusing code, and not with the language itself? I'd rather use a language where I set the constraints myself than one with "training wheels that you can't take off". (Not that I'm saying PHP is like that, but BASIC definitely is, for example ;)

Re:Why PHP rather than Perl?

[kubrick]

Actually, just saw this later on in the thread:

Re:Why PHP rather than Perl? (Score:2)
by eddy the lip (20794) Neutral on 09:34 AM January 28th, 2003 (#5170158)
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.

I guess it comes down to whether you consider that Perl encourages bad behaviour or not. I don't think it does -- in the same way that the fact that there's a full bottle of vodka in front of me doesn't mean I'm going to try to drink it all in two hours. Credit me with some self-restraint here. :)

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.

Oops. Make that PHP.NET and MYSQL.COM. nm

[fbg111]

nm

DB result caching

[digidave]

The stuff in this book is so simple that php.net and mysql.com would be better resources. I'll tell you what: if you can find me a book that tell me how to do proper database result caching in PHP/MySQL then I'll be impressed.

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.

Re:Ok, I'll bite.

[Helter]

I'm not a great programmer, but why would you need destructors in php?

Doesn't it release resources upon each page completion?

Move to Mod_perl

[Helter]

and the shebang becomes irrelevant.

Different publisher.

[AltGrendel]

Safari is a great service if you don't like dead tree versions of stuff.

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.

[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.

Parent Troll is also Dupe

[skillet-thief]

This guy really needs to get a life!

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:Why I Chose PHP Over Perl

[Anonymous Coward]

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work...

This is where I stopped reading and laughed my ass off. Just because Perl's OO capabilities suck doesn't mean PHP's are "excellent". "Rivals Smalltalk", my ass!

Re:Why I Chose PHP Over Perl

[ajs]

"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!"

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?

[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?

[Kaemaril]

Such a book is already out. Do a search on Amazon for "PHP Postgresql" --- it's in there. Only got three stars, mind you, but it's in there.

Re:Postgres?

[ceejayoz]

Speaking of PGSQL - does anyone know of a similar script to phpMyAdmin? I've been unable to find anything coming even close to phpMyAdmin for PGSQL... that's my one barrier to entry.

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.

Re:Postgres?

[mgkimsal2]

http://www.amazon.com/exec/obidos/ASIN/0672323826/ qid=1023402602/sr=8-1/ref=sr_8_1/002-9605789-10808 10

Re:Postgres?

[ceejayoz]

That looks just like what I need - thanks!

Re:Postgres?

[Anonymous Coward]

The second book out about PHP covered PostgreSQL! It's titled "Building Database Applications on the Web Using PHP3." Even though it's PHP3, most of the info is still applicable to PHP4. Much of the book is function references that you can pick-up from php.net, but IMHO the book has much better examples. Amazon link:

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.

Re:Read it on Safari without buying the paper vers

[Richard_at_work]

Im having huge problems with safari atm, one of their servers that seems to serve my portion of the internet is returning 0 byte replies, basically jsut header information and nothing else. I have emailed them and so far im getting no response. I can use it at work but my traceroutes end up at a totally different server, so im guessing they have round robin servers for different routes to their site.

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

[Kaemaril]

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

I don't understand what you mean. What's the problem with SQL on Mysql, precisely? And what "faulty levels" in SQL are you talking about? Is this SQL92? SQL99? What's your beef?

Re:Some wrong fundamental facts

[leandrod]

> What's the problem with SQL

Fuller answer at The Third Manifesto, Database Debunkings and elsewhere.

But to cut a long story short, SQL does not support relational prescriptions as data independence (SQL views are not consistently updateable), nor respect relational proscriptions (undifferentiated NULLs), nor abide by the fundamental relational principles (pointers violate the Information Principle, OO extensions mess the simple domain, attribute, tuple, relation that is central to the relational model).

> on Mysql, precisely?

Its language is not proper SQL at all: it does not support transactions properly, nor has the necessary data types, and has been adding features kinda haphazardly without neither admitting to past mistakes nor presenting a clear roadmap to either SQL or the relational model. It should be called PseudoSQL, or SubSQL, or SimplerThanSQL.

Re:Some wrong fundamental facts

[Tablizer]

MySQL is not a full DBMS either, because it leaves things like transaction control...

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

BTW, the Inno extensions for transactions are not that hard to install, are they?

MySQL is not relational, SQL violating several relational prescriptions and proscriptions....

Until the Chris Date revolution happens, SQL is what there is for the average programmer. Yes, it is an imperfect standard, but at least there is a standard. I don't know of any decent open-source "true" relational DBMS's anyhow. Unlike OSS "true" relational products, at least MySQL exists.

Re:Some wrong fundamental facts

[SoupIsGoodFood_42]

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

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

[leandrod]

> 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.

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.

> it's still a god damn database in reality, and according to your own deffinition.

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

[leandrod]

See you still did not do your homework, Tablizer...

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

First, you have to decide what you are talking about, a database or a DBMS. Putting quotes around a database does not make it a DBMS, which is quite a different thing.

Second, a DBMS is a system to manage data. Keep its integrity, allow for perfoming backup, control and enable access and manipulation. So transactions are a part of what a DBMS is supposed to do. If one dillutes a concept to include X, X is happy, but the word becames useless.

> the Inno extensions for transactions are not that hard to install, are they?

Perhaps not, and actually InnoDB is quite good in itself. But yet it does not solve all MySQL problems, while simply using PostgreSQL does.

> SQL is what there is for the average programmer. Yes, it is an imperfect standard, but at least there is a standard.

Then why use MySQL, which fails to implement it?

> I don't know of any decent open-source "true" relational DBMS's anyhow. Unlike OSS "true" relational products, at least MySQL exists.

Freedom (source code openness somehow is not euphonic enough) is orthogonal to the relational model and to the SQL standard. If freedom is essential and SQL acceptable, PostgreSQL fits the bill much better. If not, then we do have Alphora Dataphor. It is a tough choice, but luckily we are not bound to suffer MySQL.

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.

Re:Some wrong fundamental facts

[Kaemaril]

> Its language is not proper SQL at all: it does not support transactions properly

Could you clarify this? In what way does it treat transactions improperly? If you're going to say something doesn't work surely you should say why? I'm no expert, btw, I'm just curious as to what the actual problem *is*.

> nor has the necessary data types,

Which are? What standard(s) are you comparing against?

> and has been adding features kinda haphazardly without neither admitting to past mistakes nor presenting a clear roadmap to either SQL or the relational model.

This doesn't make sense to me. You *seem* to be saying that because they're adding new bits and pieces on seemingly randomly the language isn't SQL? If this is actually the case, this is rather like saying that a Pascal compiler doesn't produce true Pascal because they waited 'til the very last minute to put in the code to compile a Case statement...

Re:Some wrong fundamental facts

[Anonymous Coward]

> Its language is not proper SQL at all:

Considering about 99% of our well-written SQL statements converted from DB2 to MySQL without changing, I'd say that's not true. Yes, MySQL is missing many obscure features, but in my opinion, most of what it is missing shouldn't have been included in SQL in the first place. It has SELECT, UPDATE, and INSERT. There isn't much else considered essential to SQL. What do you mean by proper?

> it does not support transactions properly,

I do miss transactions, and I wish AB would get around to adding support for transactions to MySQL. The InnoDB hack and the DBD hack, while interesting, isn't useful for a production system.

> nor has the necessary data types

As far as I know, MySQL has all of the standard data types. A bunch of different integer sizes, numeric, floating point, characters, dates, etc.. No, it doesn't have many of the off the wall data types the PostgreSQL has (latitude and longitude? IP addrs? polar coordinates? RGB?), but for those of us that want a standard SQL server without the bloat, that's a good thing.

Re:Some wrong fundamental facts

[SoupIsGoodFood_42]

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.

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

[Tablizer]

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

Essential for what? Doing real world work or fitting Codd's list? While a nice feature, lacking it does not fully disqualify a DBMS from being a DBMS. Besides, I said DBMS, not RDBMS. The qualification for RDBMS are stricter than DBMS. Remember, the term arose in the era of IMS and Network-DBMS's.

Remember, many small companies are currently running off of MS-Access, still being the piece of sh8t it is.

Re:Some wrong fundamental facts

[Tablizer]

Second, a DBMS is a system to manage data. Keep its integrity, allow for perfoming backup, control and enable access and manipulation. So transactions are a part of what a DBMS is supposed to do.

The term arose before relational was born I believe, and perhaps before transactional integrity. (We would have to check the history books.)

If freedom is essential and SQL acceptable, PostgreSQL fits the bill much better.

Postgre does not have the acceptence-level that MySQL does. If you look at web hosters, Postgre is less commonly supported. Plus, there are more books on MySQL, as this topic seems to suggest.

If Chris Date wants to get his ideas more widely accepted, I suggest he start an open-source movement. Nobody is going to pay for something "weird", but they like to play with such if they don't have to fork over greenbacks.

Re:Some wrong fundamental facts

[leandrod]

> slight missunderstanding of deffinitions

I would say fundamental, not slight

> If it's not, I'd like you to prove me wrong since it's does infact--manage my data for me.

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.

> 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?

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.

> 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?

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

[leandrod]

> The term arose before relational was born I believe

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.

> perhaps before transactional integrity. (We would have to check the history books.)

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.

> Postgre does not have the acceptence-level that MySQL does.

And? It does not make MySQL any better, same as the wider availability of MS-WXP does not make it any better.

> If Chris Date wants to get his ideas more widely accepted, I suggest he start an open-source movement. Nobody is going to pay for something "weird", but they like to play with such if they don't have to fork over greenbacks.

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

[leandrod]

> In what way does it treat transactions improperly?

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.

> Which are? What standard(s) are you comparing against?

What about ISO SQL? Take anything from SQL 89 Entry Level, MySQL compliance is as bad as Oracle and even worse, without its robustness.

> You *seem* to be saying that because they're adding new bits and pieces on seemingly randomly the language isn't SQL?

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

[leandrod]

> about 99% of our well-written SQL statements converted from DB2 to MySQL without changing

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.

> Yes, MySQL is missing many obscure features, but in my opinion, most of what it is missing shouldn't have been included in SQL in the first place. It has SELECT, UPDATE, and INSERT. There isn't much else considered essential to SQL.

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.

> The InnoDB hack and the DBD hack, while interesting, isn't useful for a production system.

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?

> MySQL has all of the standard data types. A bunch of different integer sizes, numeric, floating point, characters, dates, etc.. No, it doesn't have many of the off the wall data types the PostgreSQL has (latitude and longitude? IP addrs? polar coordinates? RGB?), but for those of us that want a standard SQL server without the bloat, that's a good thing.

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!

Re:Some wrong fundamental facts

[leandrod]

> Essential for what? Doing real world work or fitting Codd's list? While a nice feature, lacking it does not fully disqualify a DBMS from being a DBMS.

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.

Using books vs. the Net

[NaugaHunter]

I've found that the best reason to use a book is the option to just sit and read, away from the computer. Other good reasons include being able to scribble in the corner and underline or highlight exactly what you might want to refer to.

I will grant you that it is rare to find a good pure reference book, and that for reference purposes web sites are usually better. I would propose that unless you have a large display, a broadband connection, and plenty of patience for hunting through disconnected information to make a coherent whole, using a book as a coherent whole to start with is generally an easier way to learn. (Though obviously, ones own habits/tendenancies might override this.)

And yes, I picked up this particular book and am working through it in my spare time, so to speak. Having worked with other scripting and database languages before, I found parts of it skipable or over-talkative, but it does give good information. My biggest complaint is that it doesn't have instructions on how to set up in OS X. However, going back and forth with it and information on Marc Liyanage's pages, I was able to get everything working reasonably easily.

Second Edition

[shiflett]

A new edition comes out next month that will probably address all of your concerns:

http://www.amazon.com/o/ASIN/067232525X/ref=cm_c us trec_gl_acc/002-0167781-3203215

I own this...

[cherrypi]

I picked this book up a couple months ago and so far I've been very impressed with it's blend of advanced tutorials and beginner breakdown. I have nominal programming experience with ASP and Javascript, and it quickly highlights a lot of the strengths of PHP over both of those languages. I haven't gotten into any of the MySQL stuff yet, but I assume it will be just as well written.

Re:I own this...

[Anonymous Coward]

I have nominal programming experience with ASP and Javascript, and it quickly highlights a lot of the strengths of PHP over both of those languages.

Sounds more like you have negligible experience. Apples and oranges.
Can you do client side scripting in a browser with PHP? No.
PHP may indeed have strengths over ASP and can fairly be compared as they are competing technologies.

PHP and Javascript on the other hand, are complimentary. Most people end up using both for web applications in the same way that they would use ASP and javascript together.

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

troll alert

[Anonymous Coward]

I could have modded him down, but then I'd get moderated as "Unfair" by some M2er who doesn't take the time to see the syntax.

Check out his posting history and you'll see that this is just a karma whoring post so he can build up his points.

Re:troll alert

[Anonymous Coward]

the post was on-topic and insightful. you should read the faq on moderation a bit more closely. i dont believe it says to take the users past posts into account when moderating. you might want to figure out what karma whoring actually is before you accuse someone of it

Re:troll alert

[Anonymous Coward]

It was pure fluff. It's the absolute definition of karma whoring: saying something that will, on the surface, look insightful (or informative, etc.), but is really just designed to get positive moderation. Looking at your past comments, it's pretty clear that you don't have anything of value to add, so my conclusion is that you're just karma whoring.

Re:troll alert

[Anonymous Coward]

i don't think it was fluff. it offered many valid critiques of the book including the fact that the section on normalization was poor, the SQL reference was lacking, and the PHP hand-holding was too much. if you have a personal vendetta against someone, so bet it, but you should consider not being an AC to do it.

Re:troll alert

[Flutty]

I did find this useful. I am reading the book and it is useful to see which sections a more experienced programmer finds useful or not useful.

It this guy is a troll, I am a trollkin!

I definitely agree.

[jmpresto_78]

I definitely agree. The arrangement of the topics make it very easy to use as either a reference or cover-to-cover book. It's introduced me to a lot of features that I didn't know existed in the PHP world.

Postgres... and Python or Zope

[axxackall]

PostgreSQL instead of MySQL is certainly a great improvement. But why stop on it? Python is much better than PHP as well. So, all we need is "Python and PostgreSQL" book. Or prehaps, "Zope and PostgreSQL". Any authors around there? Anyone to volunteer?

Re:slashdotted slashdot?

[axxackall]

The book is about MySQL. Slashdot is based on MySQL and it's way too slow. And now the comment about such fact is moderated as "Offtopic"? That's not very nice. You can moderate it down and down, but you cannot hide the fact that the main reason that Slashdot is slow is b/c it's implemented with MySQL. That was a wrong technology choice for such class of web-applications as Slashdot is you cannot hide using your moderations.

first book I bought on PHP -or- MYSQL

[dickens]

I had already started using PHP and MySQL, but after going through this book (and I did pretty much read it front to back) I had a much better idea of what *could* be done with PHP and MySQL.

Now I've built a couple of special-purpose content management systems, and with the framework the book gave me, I'm able to better use the resources available on the web.

BTW, I think you can safely extend LAMP to LAMPS (Linux, Apache, MySQL, PHP & Smarty).

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:How to make money on slashdot

[sporty]

Not a cricism on you or the parent... but I'm just curious.

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

[ziriyab]

1. Insert your referral ID into amazon links
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 :)

The Future

[christowang]

What comes first, MySQL 4.x Stable or PHP 5 Stable? Don't know which I've waited longer for, one of those or Duke Nukem Forever.

Re:slashdotted slashdot?

[Jack9]

Please define Slashdot's "class" of web application. I would think it fits the standard high volume message board. Drlaura.com and a number of other high-volume message boards all use mysql+php. I suspect Slashdot's slowness is a combination of bandwidth and hardware bottlenecks rather than blatant performace issues. Nobody (much less Slashdot admins) would stand for that. To do what? Get more popularity from the 'in' crowd? To make friends with the Zend circuit? There would be no real point.

2nd edition is out in 2 weeks

[Michael McGinnis]

Perhaps this posting was intended to refer to the newest version of the book?
I would suggest that anyone interested in this book either buy it used or wait two weeks for the next edition.

PHP and MySQL Web Development, Second Edition

Maybe the PHP and MySQL projects should...

[FyRE666]

team up and create a single documentation download for developers. Since virtually everyone using the 2 would be running a local webserver - why not offer a download with a MySQL database dump file of the docs, with some PHP pages to use to set it all up and as the search engine to look stuff up? It would surely be easier than having to scroll through pages for that function you've forgotten the name of - or for other functions that may be more appropriate!

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..

SUEXEC.

[FyRE666]

what can you do with perl that you can't do with php

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...

Re:SUEXEC.

[Anonymous Coward]

You can compile PHP as a stand-alone binary, and that can be used to exec stuff from the command line. I think you have to run it with --quiet or something so it doesn't spit out HTTP headers, but other than that it's like any other command line-capable language.

Re:slashdotted slashdot?

[axxackall]

Please define Slashdot's "class" of web application.

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.

Oh, gawd! You're right!

[Dthoma]

That's what happens when I just skim a function's manual page. I misread 4.0.1 as 4.1.0. Sorry to all who read my parent; it's got a factual inaccuracy error in it. (Insert embarassment here.)

Parent comment is right on.

[Dthoma]

I wholeheartedly agree. That's how I learned PHP; I read the code of others, skimmed the manual, started editing the code of others, read the manual for bits I didn't understand, skimmed the whole thing again, then started making my own projects, using nothing but the manual (and the occasional snippet of other people's code) for reference. When you get good enough you can start to get a feel for the idiosyncracies of your favourite language; in my case, PHP. I know when you'd use $_POST instead of $HTTP_POST_VARS and why you should use $_POST["subject"] instead of $subject.

A good debugger is always welcome.

[Dthoma]

Some of you seem to have slightly misinterpreted my comments. I didn't mean to say that a debugger isn't at all necessary or wouldn't be helpful; I was just saying that I've found PHP is the kind of language where with sufficient planning you can eliminate the need for a special debugger in 80/90/99% of cases.

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.

Identity?

[Acidic_Diarrhea]

Please post a comment signed in in reply to one of my other posts or within my journal so that I can identify you and add you to my foes list. Thank you.

But for beginners...

[ilctoh]

While they do an good job targetting both beginners and advanced users, it really does a good job with beginners that have little programming experience. Someone coming from C++ or Perl could probably figure out what a given amount of code does, wouldn't something like this look a wee bit intimiating to a newbie:

$dbh=mysql_pconnect('127.0.0.1','uname','passwd')
mysql_select_db('customers');
$query = 'select * from TABLE where ID > '.$minID
$result = mysql_query($query,$dbh);

Re:Read it on Safari without buying the paper vers

[iWishMeHadModPoints]

The minimal plan actually starts at $9.99. There's also $99 per year, which comes down to even less.

yes and no

[x3ro]

its a pretty good book. i read it about a year and a half ago and learned the basics of both technologies (PHP/MySQL). there were a lot of typos, sloppy writing and oversimplifcation, though .. and PHP has moved on since then - the deprecated register_globals config flag versus the new superglobal arrays, for instance .. so i hope theres been a revision and an update

Re:Fuck you. You shouldn't use OO.

[jfarrell1983]

no its not

Perl's modules are easier to install

[zabouti]

I actually like php much more than perl for web programming, but when you're working on a server where you don't have control over how php is compiled, you can't add functionality. With perl, you can install modules in user space and keep working.

I found this problem when I wanted to use the cURL library with php on iServer.

Second edition out soon

[Hyperhaplo]

http://www.amazon.com/exec/obidos/tg/detail/-/0672 32525X/qid=1043724342/sr=1-3/ref=sr_1_3/103-193927 5-1482235?v=glance&s=books

PHP and MySQL Web Development, Second Edition
by Luke Welling, Laura Thomson

List Price: $49.99
Price: $34.99 & This item ships for FREE with Super Saver Shipping. See details.
You Save: $15.00 (30%)
Availability: This item will be released on February 13, 2003.
Edition: Paperback

Thanks Amazon(TM)

Re:Things the World Needs Fewer of:

[Anonymous Coward]

1. People who reflexively complain about the inferiority of PHP and MySQL

2. People who use PHP and MySQL, giving those of us who know better something to complain about

Moderators: cut-and-paste job !

[androse]

This is a cut and paste job. The properly formatted original may be this one, but I'm pretty shure I have read the "It rivals SmallTalk" idiotic comment earlier.

Cheers

Same type o book Perl/modPerl?

[Anonymous Coward]

Is there a similar book that can be recommended for Perl/MySQL or modPerl/MySQL that uses the same type of structure as this book?

Should I be looking for Perl or modPerl "cookbooks"?

I started with Programming Perl 2nd edition, as I was told that "we are programmers!" and that the Learning Perl book sucks, not to waste money on it, and it is "banned" from the Perl 1 class I took. Well, the class was very condensed (short hours, few classes), this was my first programming language, and it was over my head. I also had other projects going on at the same time, so couldn't devote the time to it. I ended up buying the Learning Perl book anyway, as I knew I needed a good foundation. But the book doesn't have any real world examples in it, which is what I need.

From the description of this book, both in the review and in the comments, this book would be good for me, but I'm not interested in php. I have several php books already, and know I'll be using perl/modperl rather than php. So what should I be looking at that is similar to this book, and has similar real world examples, but is written for perl or modperl, and not php?

tia

Perl/modPerl?

[Anonymous Coward]

Is there a book that can be recommended for Perl/MySQL or modPerl/MySQL that uses the same type of structure as this book?

Should I be looking for Perl or modPerl "cookbooks"?

I started with Programming Perl 2nd edition, as I was told that "we are programmers!" and that the Learning Perl book sucks, not to waste money on it, and it is "banned" from the Perl 1 class I took. Well, the class was very condensed (short hours, few classes), this was my first programming language, and it was over my head. I also had other projects going on at the same time, so couldn't devote the time to it. I ended up buying the Learning Perl book anyway, as I knew I needed a good foundation. But the book doesn't have any real world examples in it, which is what I need.

From the description of this book, both in the review and in the comments, this book would be good for me, but I'm not interested in php. I have several php books already, and know I'll be using perl/modperl rather than php. So what should I be looking at that is similar to this book, and has similar real world examples, but is written for perl or modperl, and not php?

tia

Re:Ok, I'll bite.

[Anonymous Coward]

Yes..

but in some cases when you utilise a function for example that may use a LARGE amount of system memory such as a multi-dimensional hash/array that uses a 'reiterating' loop form of function you may definitely want to clean up your arrays/hashes after each reprocessment of the loop in order to save on resources and be more efficient..

Thats just one example though