Slashdot Mirror
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.
the P in LAMP stands for PHP not Perl. PHP and MySQL are a perfect fit. Perl and Mysql are a real PITA.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I have been using a MySQL / Perl solution called WebGUI for quite a while
now. It is a full CMS system that is truly open source and cross
platform, running on *nix, Windows and MacOS.
It truly is powerful yet very easy to use. Plenty of features such as Submissions system, Bulletin Board, Calendar, Syndicated Content and much more.
If you are looking for such a solution, feel free to give it a try.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Thank you, that was my immediate first reaction. Perl is a regexp manipulation language first, and very well suited for a variety of other tasks, other than web development. But, for webdev, there are many other languages that have been developed since perl that are much better.
Perl had to be adapted to web development, and it still suffers from various problems (for example, it's significantly slower than php). Php was written to be a web processing language. It's easier to understand and easier to program in, and faster. 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").
~Will
sig?
All bold is just as unreadable as all italics.
...and you've got a Ruby app to write, you'll be happy to know that Ruby/DBI is available.
It's being actively developed - a FrontBase release just happened a few days ago - and it supports a big list of databases.
The Army reading list
This will be an excellent addition to the O'Reilly books on Perl I already have.
The whole love or hate thing in the article intrigues me I might add. I love both MySQL and Perl. Why? Well, you can't beat MySQL for its cheapness facor. Let's face it, most people don't need some professional job, myself included. And as far as Perl goes, well, anyone who's used it significantly can understand how great it is for practical answers on the fly.
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.
I love perl for what it was designed to do: process text in just about any way imaginable. I hate it for the purpose proposed here: CGI scripts.
I usually use PHP for Web pages, a mixture of PHP, Perl and Bourne shell (and whatever else is at hand) for the back end, and I wouldn't touch MySQL for a database if my life depended on it, when there are vastly superior OSS altrernatives available.
How am I supposed to fit a pithy, relevant quote into 120 characters?
I personally won't use Perl for backend programming on a website but if I had to I would probably buy this book based on the fact that it is authored by Paul DuBois.
When I first started out with MySQL I bought the book titled 'MySQL' written by DuBois. Since then, I've obtained a couple of other books about it and still find myself referring to his most often.
Too bad it isn't MySQL and (PHP|Python|Java). Who uses Perl in web programming anymore?
*dons flame retardant suit*
-Pat
Nice. I'm planning on learning how to tie scripting (have decided on Perl yet but it's a contender) and databases this summer anyway. This book might make the decision as to what to use for me.
However, for those just picking up Perl for the first time I recommend the free ebook Picking Up Perl, and the ActiveState Perl Interpreter for Windows (this was a while ago-- if you are using Linux it probably aleraday has Perl installed). And then as it was Windows I was learning Perl on I used OpenPerl IDE. For Linux I recommend using Kate and Konsole.
Not trying to be off-topic here but I figure someone reading this may want to try out what this Perl thing is.
Disclaimer: Not a Perl fan at all, I actually perfer Python, but to each their own and as any Perl hacker can appreciate TIMTOWTDI! ;)
Your CPU is not doing anything else, at least do something.
?? Support your inferrence that perl is faster than PHP?
I don't have hard numbers, but I have been in environments where both are used, and perl seems to perform much worse. Specifically, I administer ~100 webservers, and clients that use more php put far less of a load on the system than people writing in perl scripts executed through web pages or mod_perl. In multiple years of working with both, perl just has become synonymous with higher system load.
The load jumps related to PHP that I see are always MySQL based loads.
~Will
sig?
Not true. There's database layers for PHP you can use that'll make your database connections heterogeneous...
ezSQL is one that comes to mind. There's plenty more.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
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?
I agree with most of your post, indeed I'd go further: MySQL doesn't deserve to be called a database at all, because it does not support transactions with commit/rollback, and cannot therefore guarantee to maintain referential integrity.
But to answer your question: I think the answer is performance, compared with Postgres. Of course it's easy to have good performance when you drop vital database functionality.
And compared with Oracle, it's price. I try to use open-source stuff exclusively, but I have to admit that Oracle is one impressive product, that has no serious competitor in the open-source world. MySQL performance (or better) with complete database functionality! For once, you actually do get what you pay for.
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.
-
ping -f 255.255.255.255 # if only
Java? Hehe.. lol.
Dude, check out SQLite. It's written in C. It's fast. And it's smaller than your java shite.
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.
This isn't a problem with PostgreSQL, but rather with it's user (that would be YOU). Perhaps you should actually edit postgresql.conf, and vacuum the database once in a while. Idiot.
Stop spreading FUD.
Here are some benchmarks you might find interesting. Particularly:
You can see from the graphs that mod_perl performs way better than PHP on the whole, and places less load on the server than PHP. They were not using MySQL.
IMO Perl is rapidly losing steam due to the enormous popularity of PHP. PHP is easier to learn, faster to master and less confusing to begin with. Not to mention, PHP's online documentation is really hard to beat sporting many easy to follow examples, a very functional layout, and features (such as the http://php.net/ search) that i'm pretty sure i've only seen mysql.com adopt.
Granted, PHP is not great for everything, but for small to medium websites (and arguably large websites as well, I know of some corporations that use PHP, see bravenet.com, one of the largest providers of ready-to-run webmaster tools. They use PHP quite extensively.). For rapid application development, it's a dream.
As we come closer to PHP5 (which is RC2 now) we're also seeing the integration of sqlite as an option which may appeal to people who just want to write small blogs and other applications which simply do not demand the need of mammoths like mysql or postgresql. This means less headache for budding programmers, and easier migration of applications since sqlite does not require an SQL server.
BeauHD. Worst editor since kdawson.