MySQL and Perl for the Web

Craig Maloney writes "MySQL (love it or hate it) is one of the most popular databases for deploying websites. Perl (also love it or hate it) was almost synonymous with website programming. Arguably there are different choices for different needs in web development (PostgreSQL, PHP, Java, etc.), but there is no argument that if you are planning on putting together a website, using MySQL and Perl that MySQL & Perl for the Web will aid immensely in that development." Read on for the rest of Maloney's concise review of the book. While not new, he says it's still a valuable volume. MySQL and Perl for the Web author Paul DuBois pages 552 publisher New Riders rating 10 reviewer Craig Maloney ISBN 0735710546 summary A clear, well written book for Perl and MySQL

Who is this book for? Developers looking for a quality book on Perl and database development should not pass this book up. While the title of this book is MySQL & Perl for the Web, it could have easily been called DBD/DBI & Perl for the Web. The SQL examples may or may not work with various databases, but the DBI interface code should remain the same. This book will also do well as a reference for experienced coders looking for well-crafted examples of web-based applications. What's good? The second chapter should be enough to get anyone up to speed with using Perl, DBI, CGI, Apache, and MySQL. After a brief introduction and configuration of MySQL and Apache, the author settles in to discuss coding DBI and Perl. The remainder of the chapter details the best practices for using Perl and DBI together. Near the end of the second chapter, the author creates a fully functional to-do list, demonstrating ways to add, update, and delete information from the database using Perl and DBI. Instead of taking small baby steps over many chapters, the author shows important concepts and best practices for those concepts quickly. Even seasoned (hardened?) programmers may learn new tricks or methodologies from the second chapter of this book.

Is that the end? Are we left with one very well written tutorial chapter? Thankfully, the rest of the book has plenty to offer. Subsequent chapters include:

• Improving performance with mod_perl
• Generating and processing forms
• Writing form-based applications
• Automating the form-handling process
• Performing searches
• Session management
• Security and privacy issues
• E-commerce applications

Each chapter is clearly written, with several examples used to demonstrate the concepts presented. The examples are clearly written, and the author makes the whole learning process enjoyable and fun. The examples range from a give-away contest (including a random drawing), an electronic greeting card program, polling programs, and a shopping cart program. Each of the examples is presented completely, but are introduced in pieces (subroutines, modules, etc.) The full source code is available from the author's website at http://www.kitebird.com/mysql-perl/

What's in it for me? MySQL & Perl for the Web is the book that Perl programmers on any project will wish The Other Guy had read. The examples are clear, the writing is engaging, and the code is maintainable. This is a practical book and should not be overlooked in any serious Perl programmer's library.

You can purchase MySQL and Perl for the Web 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

Web, schmeb

[jargoone]

Perl (also love it or hate it) was almost synonymous with website programming.

Love Perl for most anything, hate it for web "programming". There's a good reason it was synonymous with website programming. It's because there now exist more flexible, robust, easy-to-use platforms for web development.

Re:Web, schmeb

[wawannem]

Currently working in a Java/JSP/Sybase-based web programming environment and I love it.

But, I will give perl it's props.

I often use it to prototype large projects. Despite most arguments for other languages, I will say that you can pump out perl code pretty fast and it does help when you need some mockups and basic functionality to sell a concept.

Re:Web, schmeb

[Etyenne]

It well-known indeed that the plural of anecdote is data.

Re:Web, schmeb

[sporty]

No. perl is not a regexp manip language. The regular expression stuff is a subset of it, just like the data structures and what not.

Saying that perl had to be addapted to web development is just wrong. perl also, is not slower than php. Perl is a VERY modular language. You can do traditional CGI programming in it, just like php. There are many templating options as well as mod_perl, which more resembles java servlets than it does php.

Also, stating that it's clearer means nothing. At least with DBI, i know how to connect to any database. With php, there's a seperate function to open a connection to the database, per vendor. Their function names are quite conveluded, switching orders of word types, i.e. noun_verb vs verb_noun.

PHP is built for the web first, and is a programming language second.

I used to enjoy coding in Perl…

[Anonymous Coward]

...until I discovered poking myself with a sharp stick.

old book?

[inf0c0m]

does anyone else realize that this book is exteremly old?

Paperback, August 2001

also.... on the same bn site

A new copy is not available from Barnes & Noble.com at this time.

Re:Pathologically Eclectic Rubbish Lister

[Daniel Dvorkin]

I can think of nothing more likely to start a flamewar on /. than singing the praises of Perl and MySQL in the same story.

<1/2 g>

Re:Three cheers for LAMP

[Monkey Angst]

Hitler also changed the world forever. What's your point?

How the hell do you Godwin a thread about a Perl book?

Why actually choose MySQL?

[jesterzog]

Arguably there are different choices for different needs in web development (PostgreSQL, PHP, Java, etc.), but there is no argument that if you are planning on putting together a website, using MySQL and Perl that MySQL & Perl for the Web will aid immensely in that development.

Maybe so, but I still have trouble figuring out why MySQL is given so much credibility in the first place.

In the previous story about MySQL, I posted a comment asking what it actually did that other databases (including the also-free PostgreSQL) didn't do at least as well, or better. The main responses seemed to include:

• MySQL being the only DB supported for an application that someone wanted.
• People already being very familiar with MySQL's strange ways of doing things that are inconsistent with every other respected database, not to mention SQL standards.
• No other free databases having reliable Windows builds. (A Windows build of Postgres is on the way, but not yet fully complete.)
• ISP's only providing a MySQL server.
• Simply not knowing anything else due to past experience.

The Windows build issue seems quite reasonable, but the other reasons imply that the main reason MySQL is so popular is simply due to lock-in. People use it because they have to, or because they're not familiar with the alternatives --- not necessarily because it's actually better for the task-at-hand.

Perhaps MySQL is such a common name that people haven't heard of better alternatives out there. Presumably the book that this story reviews, which gives it even more publicity, is yet another reason that someone might consider MySQL without even thinking about alternatives.

Can anyone tell me if I've missed anything, though? Besides the typical lock-in reasons for using MySQL, does it actually do anything better than other databases as any sort of killer feature?

If not, and if you're looking to start learning about a database and actually have a choice, it seems that you're much better off looking at an alternative database.... whether it be a free one such as Postgres, or one of the big ones such as Oracle or SQL Server. At the very least, you'd get a more reliable database than MySQL, a more portable database than MySQL, and even postgres (just as free) offers a wealth of additional -- often useful and important -- features such as stored procedures and more complete data integrity. You'll probably also become much more familiar with correct SQL syntax ... for what it's worth.

Re:Why actually choose MySQL?

[iwadasn]

Something I think I'll point out. If you want a little toy database, consider HSQL. It's about as good of a database as MySQL (give or take), but it's written in Java (runs on anything), is about 300k or so in size, takes all of ten seconds to set up, and is actually much more SQL compliant than MySQL.

If a tiny easy to use database is all that you need, HSQL is for you. The one real gotcha though is that it can't handle datasets larger than 1/2 a GB. That's way too small for real database servers, but more than enough for most websites, even many commercial ones, I imagine.

In addition, HSQL can run within your java apps, which is really nice. I usually go for a dual pronged approach. use HSQL to handle all the file BS that you app might need (various config parameters, a small data cache that can be sifted efficiently in lots of different ways, other nastiness) and as (small) test databases to try a new idea.

For real DB work though, trade up to Postgres, and be sure to get 7.4, the 7.3.x line has a lot of crippling bugs.

The one real gripe I have about Postgres, is god, these people are in love with Hash joins. Any really good database should avoid hash joins like the plague unless it can guarantee that all the data that could possibly be returned by a subquery will fit into RAM. Postgres often wildly mis-estimates the size of a sub query, decides to hash it, and then gets killed when the query returns 100,000 rows, rather than 100.

A real database using a hash join when it doesn't know that it can take the whole table into RAM (if needed) is just begging to get run over. This is one of the few things that can really knock out an otherwise good database, and really should be considered more carefully. Hashjoins are for small reference data tables (few thousand rows), and should not be used unless you're guaranteed to be surprised.

HSQL of course doesn't have this problem, because it doesn't mess around with these "big" tables that are all the rage nowadays.

Rooting

[ryantate]

The only reasons to use perl over PHP for web development are 1.) familiarity with perl (slashdot), and 2.) security (to avoid "today's php upload root exploit").

So PHP is ideal unless, you know, you don't want to be rooted ...

Noted.

(Backs away slowly ...)