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.
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.
Linux, Apache, Mysql, and Perl. They changed the world forever.
"Website programming".
Tee-hee. I still laugh when I see that phrase.
Heh, not every website is a 50 line PHP hack made by a kid. You can do extremely powerful things with a website and those things can require complex programming skills. And that programming can be done in Perl.
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.
...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.
I find there are a lot of books and resources which each HTML, or teach Slashdot posting, but don't teach you how to close your HTML tags, or use the Preview button ...
;)
Oh, hell, you know the rest.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
...until I discovered poking myself with a sharp stick.
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?
As there are already books such as Programming the Perl DBI and Web Development with Apache and Perl, is the niche that this book is trying to fill actually worth it? Would I be better off reading Writing CGI Applications with Perl and The Official Guide to Programming with CGI.pm?
Personally, I haven't read a single one of them, so I'd really love to know. (one of these days, I'll actually read the copy of Practical mod_perl that's been collecting dust on my shelf.)
Build it, and they will come^Hplain.
Comment removed based on user account deletion
It translates roughly to this (my dingbat is rusty, please forgive me);
Blah blah blah buzzword buzzword buzzword spacefiller spacefiller blah blah this submission is now longer.
I don't need no instructions to know how to rock!!!!
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.
ASP's not a scripting language, it's a technology. The language in this implementation is PerlScript, which is pretty much - wait for it - Perl. You don't specify how this implementation of ASP makes PHP "look like a kids' [sic] toy" but I've used two implementations of ASP - ChiliSoft (now SunONE) and Microsoft's - and PHP compares very favourably to both. I'd be surprised if apache-asp differed significantly.
This is where the serious fun begins.
Perl is a superb scripting language for system coding, but...
Now with systems like Java Server Faces and Creator you can design a web form in a few seconds using a drag-and-drop designer, clip in some data validators, and visually design navigation through a complex website. A few more clicks and you have an single archive file that can be dropped into any J2EE application server, using any JDBC database on any platform.
You can design, code and test complex form-based web applications in minutes.. and all the tools are free.
So why would anyone want to hand-code all this in Perl?
Even more puzzling, given that Perl has a portable database interface, why restrict things to MySQL?
One thing that Perl has going for it that PHP doesn't is that it has correctly set up the database connection functions. Once you connect to a data source, all of the commands you use to interact with that connection are the same, whether you are using mysql, postgresql, or just a csv file. This means that you can change backend databases trivially, merely by changing one line of code.
With php, the commands for connecting to a database and running a query change, sometimes drastically, depending on the database you are using. For example, until recently if you had a query to run on a mysql backend, you did mysql_query($query) but for a postgres it was pg_exec($query). That is changing at least so now it's pg_query($query) but it still makes changing backends a large search, replace, and hope nothing breaks task.
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:
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.
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
While the idea of a 3 year old book on web development appeals to the poetry in my soul, I think it is misleading. In the last few years the Perl dev community has been making really significant progress in enabling rapid development methodologies, in particularly using tools like Class::DBI
A book which claims to detail how to do web development with Perl and MySQL and doesn't address the following issues is painfully out of date:
* Class::DBI
* SPOPS
* Kake's How to avoid writing code
With the Perl Foundation funded work on Maypole being the most recent efforts in this direction.
You may have this perception because people rarely use PHP code to do heavy lifting.
I would have to agree with you here. If you are going to compare speed of perl to speed of php, you have to compare the two doing the same thing.
Also, You cannot forget CPAN. The PHP folks will typically say something like, well we have PEAR. Unless PEAR has made some amazing strides in the last year or so, it is still no comparision to the massive body of code that CPAN provides.
-- john
It's just the alternatives I suppose that have me truely confused.
A fully featured website (which needs it all), has several layers, at most:
The client-side dynamic content, javascript, vbscript, etc
The middle-ground dynamic content,
SSI's, PHP, ASP
And the backend,
Perl, C/C++, Java, (insert any true, full blown, fully featured, programming language here, which none of the above are).
There are places where these overlap, there are number of things you could do in Perl, PHP, ASP, or with SSI for instance, which it should be done with is a matter of efficientcy of course and preference when it's just as fast at 100,000 simultaneous connections either way (even if you only expect 5). But something like PHP is not a replacement for Perl anymore than Perl is for PHP.
It's apples and oranges guys, if you want to compare something go with the SQL database flames, at least there you are comparing pretty much the same thing to pretty much the same thing. And there that same thing and generally used for the same purposes.
I freelance professionally with both perl and php. I like them both. Perl is my first language. I find that it's easier for me to use php when I'm using techniques I already know, and it's easier for me to use perl when I'm learning new techniques. php has a way of penalizing you for experimenting, it's kind of inscrutable in terms of doing what you'd expect. Perl is great that way. But when you know exactly what you're doing, php is cleaner.
If you're the kind of coder that has an urge to make things complicated, then perl is better. But I find that as I get more experienced and senior level, that I aim more towards making my code as simple and elegant as possible. I aim towards frameworks rather than applications with a lot of anticipated features. You want the application layer (in MVC terms, the control layer) to be as thin as possible. I find that I rarely need to even do things like subclass other classes. A lot of highly competent but inexperienced programmers tend to overengineer things, make too many layers of interface, use too much API, write utilities to write other utilities, get stuck in meta-land. It's like the people that declare that they can't use anything that can't do multiple inheritance. It's silly.
All you need to do is just get the job done without coding yourself into a box. Design, design, design. Architecture, architecture, architecture. You can make six figures with a solid understanding of MVC. The language choice doesn't really matter all that much. You'd be surprised how much syntax I don't have memorized. You'd be surprised how little code I write. And I can still get a lot better - I'm only started to work with Class::DBI. I'm only starting to work with php 5.
skkkoooonnnggggkkk ptui
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.