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.
..isn't meant to be used for whole paragraphs, because it is hard to read.
"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.
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!!!!
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.
Seriously, when your type in BR 5 times after each paragraph, don't you feel that at least 3 of them are superflous.
It's bad enough we have people posting the slashdot FAQ at 60 second intervals.
And what are the 2 linebreaks after the end of your post for? Deliberate annoyance? Extra scrolling pleasure? come on.
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 both are supported by interface layers like jdbc/odbc, as well as perl, php, and so forth ...
By that, do you mean most people don't need more features, as in PostgreSQL and Firebird? Both are free (in fact, more free, if you consider MySQL's licensing requirements for businesses)
How about MySQL actually accomplishes what I want to do for a reason?
:)
I love people screaming that the tool I am using is wrong, when they have no idea of just what I am doing. We also use Oracle, where needed, but we run MySQL 24/7/365 in an incredibly mission critical spot and are very satisfied with it. We tried other DB's and technologies including:
LDAP (Open and Sun/Netscape's)
Oracle
Postgres
Informix (Ok we still had a license and were bored
and none of them offered any better stability and only LDAP matched the performance in reads. Writes MySQL blew LDAP away so thats what we run. since we need good read & write speed.
As for what MySQL does better? Thats easy speed. The team started with that as its goal and kept performance in their sights the entire time. The pushed back other things, like row level locking, sub-selects, and views expressly for the purpose of running quickly. This is obviously not the right approach for some applications, but for most database driven web sites it makes perfect sense. Honestly, how many web sites really need triggers and stored procedures? There is a reason that LAMP has changed small/medium web site development business, and while its not right for all sites its a perfect fit for the vast majority.
Who uses Perl in web programming anymore?
:-)
We use it at my company for the vast majority of our web programming tasks, and it works very well for us. Reasons I personally like it:-
* Contorl. While PHP may do a lot more for you (e.g. form parsing), there have certainly been issues related to how it did things. In Perl you can do it as you want. If you put this in a module, as we did, then Perl is no more work than PHP beyond that one-off cost.
* I find the Perl database access model preferable to PHP. Correct me if I'm wrong, but it seems to me that a lot of people end up writing database classes to encapsulate the mysql_whatever or pgsql_whatever methods. In Perl it's OO from the start. Furthermore, if you change from using one database server to another, you only have to make the change in the connection string, and not to a load of function calls.
* Perl puts pattern matching tools right into your hands - it has an operator (//) specially for pattern matching. A lot of the security issues I see in web development come from improper validation. Pattern matching is a powerful tool for writing validation and Perl makes it easier to do than other languages I've seen.
* CPAN. Perl has modules for a wide range of things. Need to look at the headers of uploaded MP3 sound clips to check they were encoded properly? We found a module on CPAN to do this within minutes. CPAN is an amazing resource.
Just my few thoughts on why I belive Perl isn't dead for web programming by any means.
Jonathan
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.
I'd still recommend MySQL if you are just starting to learn SQL language. If, however, you are looking for a fully robust database with 100% guaranteed data integrity, I'd say go with Postgres.
I always remember 2 years ago when I first started researching free SQL databases. I tried out MySQL and Postgres. I stuck with MySQL because it was easier to setup, the documentation was much better and at the time it was much faster. It also didn't have an easy way to get the recently inserted auto increment field. Fast forward to today, I now use Innodb for my tables and am willing to sacrifice some speed for more integrity.
After the news story a couple days ago, I went and installed Postgres and here's my experience.
- Setup was pretty straightforward.
- Documentation is pretty good though MySQL docs are still about twice as good.
- I still can't figure out how to get the list of tables that my db currently has. I've searched the docs. Please enlighten me.
- I also still can't figure out how to get the definition for a table I just created. Feel free to point me to a page that shows my stupidity (or ineptitude in reading / searching docs)
- After going through the docs and trying some of the advanced features (things that MySQL doesn't have). I really love VIEWS.
- Postgres still doesn't have REPLACE even though it is not a standard SQL command, it's still nice at times. I could probably learn to live without it now though.
With these things being said, I'd probably use Postgres over MySQL now. Why?1) I don't need commercial support
2) I haven't worked on a project in a long time that requires speed over data integrity.
3) VIEWS
If I needed commercial support for a project though, I'd obviously have to drop Postgres. Since MySQL is the cheapest out there and it now does support some base level transactions, It's definetly the best bang for your buck. Oracle is pretty damn expensive.
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.
phpPgAdmin is available, although perhaps that's what you already tried.
Also, there's pgAdmin III which is a nice database tool, but it's not web based.
Personally I just use psql, which is command line, but I understand a lot of people don't like to work with a database that way.
Social scientists are inspired by theories; scientists are humbled by facts.