Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Perl Books Media Programming Book Reviews

Programming the Perl DBI 59

Never content to rest on his laurels, chromatic has again supplied us with a no-nonsense, informative book review. This time it's of O'Reilly's Programming the Perl DBI, for those of you unwilling to let any TLA go unconquered. If you're building a Web site or learning MySQL (or any other database) and want to combine Perl skills with data storage, he's got a few words for you. [Updated 13 June 3:20GMT by timothy:] Heck, it's a double header! PotPieMan gives a different perspective on the same book, all below.

Programming the Perl DBI
author Alligator Descartes and Tim Bunce
pages 346
publisher O'Reilly and Associates
rating 8.5
reviewer chromatic, PotPieMan
ISBN 1-56592-699-4
summary Everything you need to know about the Perl database interface, straight from the source. Store, update, and retreive information -- or even write your own database driver.

*

Review No. 1: chromatic

The Scoop

At some point in your programming life, you'll run into the idea of persistence. Whether data mining or storing customer information gathered from Web forms, data will end up shelved somewhere. Luckily for the Perl monks among us, we have the excellent DBI (DataBase Independent) module to provide a layer of abstraction and compatibility for multiple database systems. This book makes a great introduction and reference for the DBI.

Newcomers will quickly come up to workable knowledge on database concepts like basic SQL and relational models as well as Perlish constructs like object storage. Experienced users can use the included DBI specification as a reference and Appendix B for particular DBD quirks and caveats.

What's to Like?

The writing is exceptionally crisp and clean. A DBI novice could absorb the knowledge of masters in just three hours, simply by reading the chapters. It's hard to imagine a better explanation of most concepts. The quality is consistent, as is the data being manipulated. As soon as the relational database concept comes on stage, so does the sample database used throughout: a list of locations and descriptions of megalithic sites in the UK.

The real meat starts in chapter four, with a discussion of the DBI architecture. Get used to manipulating statement handles -- you'll be doing a lot of that. Be sure to follow the recommendations for quoting and error checking, to save yourself hours of tedious debugging! Chapter five continues the tutorial, exhaustively covering database interactions. As usual for O'Reilly books, the authors take pains to point out benefits and drawbacks of different approaches. As there are multiple ways to pull rows from a completed query, and which fetch method is most efficient, or more flexible? The Advanced DBI chapter talks about database attributes and metadata -- ways to communicate with underlying DB and to massage data there. There's also good information about optimizations and transactions.

The material covered doesn't stop at the title. Chapter 7 talks about ODBC -- which may be preferable in some cases. Along the same lines, chapter 2 introduces all of the most important database concepts (Storing, Updating, Fetching, and Deleting) by looking at non-SQL means for storing data. These include Data::Dumper, Storable, flat files, and the Berkeley Database Manager. Though DBI receives its due for flexibility, portability, and power, the more tricks in your toolbag, the better you'll program. If you're new to the concept of persistent data storage, it also serves as a good introduction.

Porters and rogue programmers will appreciate Appendix B: an analysis of 13 database systems and their DBI drivers. Information on special syntax, SQL flavors, and supported DBI operations is included. Be sure to catch the gotchas and issues of your particular database. Administrators will appreciate chapter 8, which discusses the DBI shell (useful for testing SQL statements and connections) and the DBD::Proxy modules (providing compression and encryption as well as query forwarding).

What's to Consider?

Perhaps due to the clarity and simplicity of the writing, the tutorial-esque DBI feature section, is rather short. Of 186 pages, 46 cover non-DBI mechanisms (chapter 2). That's not to say that there's anything missing, but that you might reach chapter six and ask, "Oh, is that all?" Adding another example database might flesh out some illustrations -- demonstrating how to solve two different problems would reinforce the important concepts.

The Summary

With its clear explanations and concise reference value, serious Perl programmers ought to make room on their shelves for the Cheetah. When you're knee deep in your first serious Web project, or bundling information from one database to another, you'll happily reach for Programming the Perl DBI.


Review No. 2: PotPieMan

The Scoop

Programming the Perl DBI starts with the basics: flat-file databases (like /etc/passwd) and DBM file libraries. Most of us have implemented some type of database system using tab- or comma-delimited files, and the authors use these flat-file databases as a starting point for the rest of their discussion. First, they give an overview of the various functions that a programmer might want to perform on data that is placed in a database. This leads them into an organized explanation of the DBI and the advantages and disadvantages of using the DBI.

What's Bad?

My main gripe about this book is that the DBI programming examples seem very basic. Granted, the book is specifically written about DBI programming, not manipulation of data retrieved by the DBI. Depending on one's perspective, this can be bad. If you are a CGI programmer expecting to find all the answers on designing a database-driven Web site, you will be slightly disappointed.

What's Good?

On the other hand, if you have any skill as a programmer, you would be able to use this book as a great starting point for database-driven Web sites. It gives a great overview of all the important functions of a relational database and the structured query language. At first, the authors give examples of SQL statements, without any actual Perl code. They move slowly through the query language so as to make sure that the reader understands, and include a few tables to structure the discussion of the SQL operators. The authors then discuss queries over multiple tables, along with primary and foreign keys. Next, the authors discuss SQL statements to modify (insert, delete, and update) data.

The actual DBI programming sections begin with an explanation of the DBI architecture, which allows them to introduce all the elements of a Perl program that would interface with a database and grab data. The authors begin with a very basic program and then expand on it to include error checking, parameter binding, atomic fetching, and so on. (The parameter binding section is particularly informative.)

For the most part, programmers looking to get into database programming would be set after the first five chapters. The sixth chapter is concerned with advanced DBI programming, and does not seem absolutely necessary to read the first time through. However, its explanation of transactions will most likely be important. There is also a chapter that discusses ODBC and the DBI, which might be important if you have to deal with Windows machines or other ODBC data sources. The chapter gives a comparison between the DBD::ODBC and Win32::ODBC modules, which is nice. Finally, the eighth chapter concerns the DBI shell (dbish) and database proxying, which might be important to some.

The appendices are quite comprehensive. The authors (using man pages as a reference) go through all the nuts and bolts of the DBI and the various DBD drivers. Overall, Programming the Perl DBI gives a substantial explanation of utilizing the DBI.

So What's In It For Me?

On the one hand, if you already have Perl experience and are new to database programming, you should consider picking up this book. To be honest, I did not know much about the DBI until I read this book. Now, I am relatively confident in my ability to implement databases in my programming. If you already have experience in programming with the DBI, though, you might not need this book. The last few chapters might be helpful, but it would be good to flip through the book before buying it.


Purchase this book from ThinkGeek.

Table of Contents

  1. Introduction
  2. Basic Non-DBI Databases
  3. SQL and Relational Databases
  4. Programming with the DBI
  5. Interacting with the Database
  6. Advanced DBI
  7. ODBC and the DBI
  8. DBI Shell and Database Proxying
  1. DBI Specification
  2. Driver and Database Characteristics
  3. ASLaN Sacred Site Charter
This discussion has been archived. No new comments can be posted.

Programming the Perl DBI

Comments Filter:
  • Sure, sites like /. probably don't need all the features

    Erm, I thought slashdot were funding the development of transaction support for MySQL?

    but when you're dealing with $50k+ orders on the websites, you'd better believe it that these orders better not go "missing" due to *anything*

    Oracle! :-)
  • Looks like another Good Thing for Perl from O'Reilly. So are they ever going to do a book on Postgres?
  • by Uruk ( 4907 ) on Tuesday June 13, 2000 @05:15AM (#1005877)
    I learned the perl DBI from Mark Jason-Dominus' Article [perl.com] on Perl.com [perl.com].

    It's quite a good intro, and I'd recommend it to anybody who knows perl fairly well. You don't even have to know much about RDBMS.

    That article, paired with the perldoc information on the DBI is fairly decent to at least get started. The perl DBI book reviewed here though is good too if you want to go a bit deeper.

  • by TheOtherGuy ( 169206 ) on Tuesday June 13, 2000 @05:18AM (#1005878)
    I grabbed a copy of this when it came out... its pretty easy reading. We use mainly Sybase here, with a smattering of DB2 and Oracle, so keeping things consistent between databases is a really nice feature; and this book has a good section about the differences in DBI between the different databases (which is what makes it worth the money.) If you aren't familiar with DBI, but are familiar with databases in general this book is a great companion to use in doing a migration. Its well written and organized; and works well as a reference manual where you just want to look upo the one paragraph that tells you what to do. (sure its got the standard I am a tutorial stuff, but who wants to read all that?) Summary: - easily accessible to any level perl programmer - well organized, good index - very useful as a reference - great chapter on the DBI spec itself for those of us who hate reading pod when we don't have too
  • Erm, I thought slashdot were funding the development of transaction support for MySQL?

    Well, uhm, I completely forgot about that, but my point is, slurping up a user's comment *probably* doesn't require as much rigor from the db as an online auction system.

    Oracle!

    Exactly =] Seriously, when I do development on my own, I find the Oracle license costs to be prohibitive, so I tend to use PostgreSQL. It may not be nearly as fast, but it has *almost* everything I need.

  • another great thing about this book is the excellent reference it provides for sql syntax and data models ... I have used it a number of times to extract information on the data structures used by mySQL, a reference which has saved me many hours of parsing through alternate documentation or program source.


  • but when you're dealing with $50k+ orders on the websites, you'd better believe it that these orders better not go "missing" due to *anything*.

    You better believe that when dealing with First Posts and rude comments about Miss Portman, these things better not go "missing" due to *anything*

    I think this is dealing with more of an Intro to Medium level DB programming, I see it more for the crowd "Hey I want to hack on slashcode and build a "favorite hot grits" survey form", not the 200 million dollar a day ecommencre site (though this book is a good place to start learning (provided you know Perl)). This is a really good book to learn the concepts and implenation on a low level. Most people just learning this stuff (like me) don't have the $$$ to chuck over to Orcale so that we can have a %100 uptime on our 28.8 dial up server...

  • People love MySQL since it is the right tool for the right job. If you don't need Transaction Support, and your smart enough to get around the the lack of Sub-Selects, then MySQL is what you need.
    One thing people have to know is that MySQL is *REALLY FAST* and in a web enviroment, speed is everything.

    As a side note, when I got hired at this job, that was one of the things I pushed. Our customer database did not need transaction support, so I argued that we did not need MSSQL or Oracle. Why have all that overhead for something that is not needed. When the customer DB is updated, then its okay if I have it do slow updates with locked table. It only takes about .5 seconds on our DB. So in worst case, queries take .75 seconds instead of .25 seconds when updating.

    Another thing people don't see in DB is the hardware. We run hardware RAID 5 on our setup. If a disk goes bad, we replace it, and it is rebuilt on the fly. Use ECC RAM to make sure data is not corrupted in memory (Sounds funny, but it can happen). Use a SCSI controller that has a big Cache (Smart RAID 5 with 64 megs of Cache in our case), and give the DB lots of memory. And for God's sake, put the stupid thing on a Battery Backup.

    However, if you need transaction support, then use MySQL 3.23 (Still alpha), Oracle, or PostgreSQL.

  • it's just you. of the past 10 book reviews [slashdot.org], only two have been o'reilly (this one, and the user friendly book [slashdot.org]). Twenty percent may seem like a lot, but then again they make lots of quality books on lots of topics.
  • by Frank Sullivan ( 2391 ) on Tuesday June 13, 2000 @05:33AM (#1005884) Homepage
    While we're knocking MySQL, let's bring up a few other inadequacies... lack of triggers, stored procedures, or referential integrity. Dropping transactions in the interest of performance i can understand, although that does prevent it from being a solid solution for e-commerce or anything else that needs real reliability on complex actions. But lack of stored procedures, triggers, and referential integrity (foreign keys) makes it *much* harder to write safe, reliable databases - you either write those checks into your code directly (or wrapper libraries), or you deal with data becoming inconsistent on a regular basis. They're pushing the work of maintaining a consistent database out of the engine and into programming and administration - this is bad practice.

    But the kicker for us recently, though, was the date checking routines. They check that the year, month, and date are all valid, but *not in reference to each other*. So Feb. 31 is a valid date, as far as MySQL is concerned! Geez. No transactions, no stored procs, etc - those are valid design decisions, even if i don't agree with them. But the date handling is just plain flawed.

    I wish PostgreSQL were a better solution. But we looked at it, and it has its own set of narrowminded shortcomings. For example, no cross-database joins, even on the same server! When asked how to do that, the developers respond that you should just put all your tables in a single database. Bwah? Oh, and you can't even switch databases on a single connect - you have to drop the connection and reconnect. This kills much of the usefulness of having transactions, and violates the development model that has been proven useful by every major commercial RDBMS.

    Wonder why Sybase, Oracle, Informix, DB2, Ingres, and SQL Server get away with charging what they do? Because their products are worth it. I'd *love* it if the Free World would develop an Oracle killer - a Free RDBMS that does transactions, stored procs, triggers, referential integrity, flexible permissions, cross-server transactions, powerful dump/restore facilities, live failover, and all the other great things the commercial products do. But it ain't happening yet, and considering that MySQL does such a great job of impressing those who don't know jack shit about serious database programming, i don't have much hope for it.

    --
  • Oh, save us, Bob. Here comes another flamewar. :)

    There are historical reasons for why MySQL has acheived its current level of popularity. First off, older versions of MySQL have been GPLed, and all are available at no cost (unless you're going to repackage & sell it [mysql.com]). That puts it in a very limited category of databases.

    Until very recently, MySQL's only competition within this segment has been Postgres. Many people perceive Postgres as being more difficult to use than MySQL. And frankly, it is, especially if you're using only the command-line tools that come with the distribution. Furthermore, MySQL actually does offer some flexibility that Postgres doesn't, especially when it comes to modifying table properties later on.

    Frankly, I'm not at all surprised that there are so many people using MySQL. It's great for jobs where transactions aren't of blinding importance, like, say, discussion boards just like this one.

    You may find MySQL inadequate for your needs, but I'm willing to bet that most of the users of the software don't use it to handle $50K+ orders.

  • by Anonymous Coward
    I found out that Bookpool (www.bookpool.com) is having up to 44% discount on O'Reilly's books right now. Naturally I don't work for them nor do I get referral fees...just thought it would be useful for others to know...
  • Yeah, it sucks to buy books that are, you know, useful and intelligent and well-written.
  • Moderate this up. I too deal with lots of _very_ important transactions. Transaction support is just too valuable in some situations to ever be dismissed. $.02
  • Just my take on those points as another PostgreSQL fan...:

    "For example, no cross-database joins, even on the same server!"
    Hmmm. I can see that as being a bit of a bummer.
    'create view c as select * from fw.current; ' doesn't event work. I'd have thought that would be nice.

    "Oh, and you can't even switch databases on a single connect - you have to drop the connection and reconnect."
    Do you mean that psql does a complete disconnect() and connect() sequence when you do \c in it?
    FWIW in my days with a certain commercial ODBC driver company, I noticed that you can quite easily get PostgreSQL to do bounce-point connections (ie use one set of client libraries of postgresql's to connect to a 3rd server instead of just the remote end of the ODBC connection).

    What I don't see is how flipping databases and mixing databases in your joins "kills much of the usefulness of having transactions".

    Oh yeah. Before I forget, on a quick benchmark test, the main problem with PostgreSQL would appear to be that inserts and updates happen synchronously causing major amounts of disk blocking (so much so, if you look in `top' then postmaster is mostly in state 'D'). In a perl script (using DBD::Pg) I wrote, I have to do one select, then either one update or insert statement. I've got prepared statements for each of the above (does MySQL have those??), it's just that removing the insert / update calls makes the whole thing run 8x faster. Oops. "I wish postgresql were a faster solution"... :)

    Don't deny what things you *do* get in postgresql - transactions, triggers, stored procs, foreign keys IIRC, UDTs, nice permissions, dump/restore. That leaves lacking fail-over, cross-server transactions, and... erm... not an awful lot. IOW, it's *close*, don't knock it when it's the most featureful we've got! :)

    "MySQL does such a great job of impressing those who don't know jack shit about serious database programming, i don't have much hope for it"
    I'd agree with that. With it you can do nothing, fast.
    ~Tim
    --
    .|` Clouds cross the black moonlight,
  • Note to story poster: The first two words of the headline are invisible unless highlighted in light mode due to the color tag. (Netscape, Win98)

    <FONT COLOR="#FFFFFF">Book Reviews</FONT>
  • You can get oracle for cheap to free for linux, for non-profit/trial use.
  • In Zelaznyish terms, O'Reilly is the one true publisher, of which all other publishers are but a mere shadow.

    In a more concrete fashion, ORA has more books on more geek subjects than just about anyone else; And they don't suck. Not all of them are good; None of them are crap, in my experience.

  • They're pushing the work of maintaining a consistent database out of the engine and into programming and administration - this is bad practice.

    As always, it depends.

    If you're building an application around a specific database, and you want it to deal with as much as possible, sure, you want stored procedures, triggers, transactions, and as many integrity checks as possible.

    If, however, you're building a database-backed web site, you want a commodity DBMS: one that's not going to take over every aspect of your system. Because chances are your project is going to have to run under a different DBMS on a different OS at some point in the future, or you'll need to rebuild the database from scratch. If you've sold your soul to Oracle once, your applications are decommoditised, and you're stuck with them.

    Regarding transactions: well, HTTP is stateless, innit. The only way you're going to lose integrity with a half-done transaction is (a) through faulty programming and (b) through hard disc crash, kernel panic or some munchkin turning the server off at the mains. In both cases you may end up with more to worry about than whether the transaction finished or not. If you're that worried about data integrity you'll not only need a transaction-capable DBMS, but also backup databases and/or RAID.

    Most websites don't need this. The MySQL folks deliberately tell you MySQL shouldn't be used for applications where this stuff is important. But everyone still has a rant about it whenever MySQL is mentioned on slashdot.

    ...or when Perl is mentioned, come to think of it. :-) Now, I'm as much a Python bigot as anyone, but isn't the Python DBI spec a bit of a mess in comparison? Well, it would be nice if more things conformed to it, anyways...


    --
    This comment was brought to you by And Clover.
  • Feb. 31 is a valid date [...] the date handling is just plain flawed.

    Feb. 31 is not valid, it's interpreted. It's interpreted as "the 31st day after the beginning of Feb.", which will result as either Mar. 3 or Mar. 2 depending on the year.

    This is a very useful feature. You have to choose: should the database engine be able to

    • compute correct date arithmetic (increment the day to "Dec. 32", take care about overflow)
    • or check a user input validity
    I believe the first one is much more useful.
  • PostgreSQL has transactions, but it isn't a speed demon. Any /.er's out there have any experience with it?
    --
    E.
  • I've been using the Perl DBI for about two years now, and recently convinced a cow-worker to look into using DBI/DBD instead of parsing thru flat files.

    I gave him a pointer to Symbolstone's DBI website [symbolstone.org], showed him a couple of small routines that he could get started with, and he was off and running!

    He was so excited about DBI that he rushed out and bought the O'Reily book, but after reading it he was very dissapointed in the book, and said that the resources that I gave him were much more useful, and timely.

    In any case, I checked out the book and found that it was fairly full of "fluff".

    Upon reflection, I think that it would be difficult to put together enough material on DBI programming to make a book-

    DBI programming really isn't all that complicated
    ---
    Interested in the Colorado Lottery?
  • Comment removed based on user account deletion
  • I bought this book right after it came out, and it helped out quite a bit. Granted, I hadn't used DBI before, only ODBC. I agree that there's nothing earth-shattering in the book, but I find it to be a good tutorial and reference, especially for those who prefer dead tree docs.
  • Comment removed based on user account deletion
  • Oh yeah?

    First, there's POE [cpan.org] which is almost an operating system in and of itself.

    And then there's PerlOS [ebi.ac.uk] here.

    Be afraid, be very afraid.

    :wq!

  • ..those of us who hate reading pod..
    HOW CAN YOU HATE POD?!

    You are a fraud. You don't use Perl and you never have. You don't know what Perl stands for, nor do you know what it can do. Anyone who makes the above statement must be a GW-BASIC programmer.
  • <i>Wonder why Sybase, Oracle, Informix, DB2, Ingres, and SQL Server get away with charging what they do? Because their products are worth it. I'd *love* it if the Free World would develop an Oracle killer - a Free RDBMS that does transactions, stored procs, triggers, referential integrity, flexible permissions, cross-server transactions, powerful dump/restore facilities, live failover, and all the other great things the commercial products do.</i>

    They sell because companies don't like free stuff. They use the logic that what you pay for is what you get. Linux is free and better, but people still use NT. Minor differences in quality is of no consequence. Comapanies want to know that there's a company backing the product they use.
  • Thanks Uruk -- this is great! I printed it... now i just have to find out how to print man CGI. Are there any suggestions or gnome programs to help me? i did man CGI > mancgi but it sucked with all the dates and page numbers on every page.

    Mike Roberto (roberto@soul.apk.net [mailto]) -GAIM: MicroBerto
  • Kill the heathen. :) POD is one of the neatest things I've ever seen, like Javadoc on steroids.

  • Moderate that up to interesting, there are very good points in there, and I don't see anything offtopic here...
  • ...but I haven't read it yet, so I can't comment on it. I'm thinking about setting up Yet Another Slash Site, so I went by a half-price bookstore in the same shopping area as a B&N looking for books on SQL.

    I got lucky. They had one copy of the O'Reilly MySQL book, and half a dozen copies of Perl DBI, so I got one of each of 'em. (They also had half a dozen copies of the mod_perl book and one of Apache, but I already had those.)

    I didn't even have to go to B&N.
  • No problem - I was just as glad to find these when I first did. BTW, when on the perl.com page, you should find MJD's name, and click on it to see a list of the other articles he's written for perl.com. It will make you a better perl hacker.

    Also, see his personal web site at www.plover.com [plover.com] in the perl stuff section. He has some good articles on the way regex's really work (NFA's) and other things.

    He's a good writer, and I haven't found anything he wrote on perl that I didn't like. (There were a few things though that didn't apply to me or were a bit too basic intended for beginners)

  • Looks to be their new way of doing titles. Nice idea, but needs fixing :)
  • As at least one other poster has commented, 1/2 Price Books [halfpricebooks.com] (they use php) sometimes has a good selection of O'reilly books; I got Linux in a Nutshell there about 2 months after it came out. The spine was a little unglued (maybe Oreilly sells 'seconds' to HPB?) but that was fine with me -- good trade :)

    Dunno how different their stock is city to city; I frequented several of their Austin locations and preferred them to the various Big Full-Price Chains when it comes to having a more interesting (not always more complete) stock, but I have two gripes about HPB:

    1) They ought to wake up and serve the coffee :)
    If anyone from HPB is listening, *please* at least establish a pilot program (who knows, maybe they already have) serving hot cocoa, tea, coffee, snacks ... I know there is a *lot* of hassle to this (food regulations which make it tough) but it would be great to go to a bookstore like 1/2 price, where one can actually afford a few books in addition to coffee, rather than to Narnes and Boble, where both categories are pretty damn expensive. The books-n-foodstuffs combo is so tempting that I (and how many others?) use it as a library where you don't have to sneak in food. Some books I've come back to several days in a row to finish, justified in my cushy chair by a refill of cocoa or coffee.

    2) Inventory control: I know that the stock changes constantly, that used books are sometimes tough to track down, etc, but the biggest problem I have with 1/2 price is the tantalizing feeling that the book you're looking for really is there, but no one can prove it. Heck, require people to tap in the info from their wanna-sell books to build up your inventory database! :) ('Sir, you'd like to sell that stack of novels? Certainly, if you could just enter the information at this terminal ...") Or offer a bonus to anyone willing to accompany books-for-sale-or-trade with a typed, scannable list of author, title, category, ISBN, etc. I'm sure they're working on this, but that's another reason why my business sometimes strayed to stores which I actually liked less -- money (and time) talk, all that.

    timothy
  • I used to love O'Reilly books. I could buy then knowing I was going to learn something and become a better programmar by reading them.


    About a year ago I decided this was no longer true. It all started with "Programming Web Graphics with Perl & GNU Software", which was a slapdash, shallow, and incoherent look at some totally unrelated ways to make pretty pictures. Increasingly since then I've felt that O'Reilly is simply try milk the customers for all they're worth. Coming out with properly named books to capitalize on each emerging trend, timed sort of like movie releases to catch you just as your wallet and trust are recovering from your last O'Reilly purchase.


    I spent a while flipping through the Perl DBI book, I found it trivial. It assumed little to no knowledge of anything, and used the example of text based file, and didn't really get into some of the cool wizardry you can do with DBI.


    I've stopped buying O'Reilly books without a direct reccomendation. Now I buy Manning books!

  • I work at a Linux company. I love Free software. And, in many if not most cases, the Free stuff is better than the payware. So why are the DBA and i harping loudly to get Sybase in here, and complaining about MySQL's inadequacies? Because these are not "minor differences in quality". These are HUGE differences in feature sets, differences that drastically affect development time and maintenance. And quite frankly, no Free RDBMS offers anywhere near the *useful* features of the commercial products.

    MySQL is great for some purposes - guestbooks, web logs, and other trivial tasks. But for more difficult tasks, it has serious scalability issues that we have to code around. I'm not some clueless manager terrified of GPL. I'm an experienced database developer. I understand what MySQL can and cannot do. And there are too many things it cannot do for the tasks we're trying to do. Sybase does those things, along with Oracle, Informix, DB2, even SQL Server (speaking of get what you pay for crap). Any experienced RDBMS developer/DBA who has worked on serious problems will tell you the same.

    --
  • O'Reilly is a rare bird -- a publisher whose technical books are usually literate and readable by those not already steeped in the topic. (They also have great introductions which tend to be great essays in themselves -- I wish O'Reilly would put all the introductions on their Web site!)

    They tread the magic line between condescending and intimidating very well, and when a book has pressing prereqs, they're usually well-explained and justified in the introduction, so a 2-minute scan is enough to determine if it's worthwhile to you.

    The happy medium between technical overload and hand-holding I think is why Running Linux is so popular -- the first few times I tried to install Linux ("what's a root disc, and how is it connected to a boot disc?"), it was with books which I now use to refer to in some cases, but which were much more intimidating. Running Linux I credit with getting me past the point of frustration and finally getting things to gel.

    timothy
  • Bruce Momjian (from the PostgreSQL steering committee is currently working on a book for Addison-Wesley. Not only is the book very good, but it is also available online at the PostgreSQL web site [postgresql.org], and is available in either HTML or PDF formats.

    The book is pretty complete, and even has sample programs using the 13 (Yikes!) available programming interfaces. Allowing you to compare the interfaces to Python, Perl, C, PHP, Java, and all the rest. Although I have to admit that it is a little strange that Bruce's Perl example is using the Pg module and not DBD::Pg. For those of you that are curious there is a DBI interface for PostgreSQL, and it is quite good.

    Unfortunately in this particular case it would appear that O'Reilly has been beaten to the punch. I would highly doubt that O'Reilly would be able to find someone that knows PostgreSQL as well as Mr. Momjian, and the book is very well written. So if you are like me and use PostgreSQL quite a bit you will undoubtedly have to settle for at least one book on your bookshelf that isn't from O'Reilly. It's too bad really, I sort of like having all of my books match, and the O'Reilly Animal Series covers are very cool :).

  • So if you are like me and use PostgreSQL quite a bit you will undoubtedly have to settle for at least one book on your bookshelf that isn't from O'Reilly. It's too bad really, I sort of like having all of my books match, and the O'Reilly Animal Series covers are very cool :).

    <chortle/> My technical bookshelf is predominantly from 2 publishers/labels: O'Reilly and Coriolis. However, I have been happily impressed by the "New Riders" series. Also, the Ventana "<FITB> Programmer's Reference" series is nice for functional references, especially when you can find them in hardbound!

  • there are very good points in there, and I don't see anything offtopic here...

    ummm ... except maybe that it's a rant about MySQL, and this is a review of a book about the Perl DBI?

    This isn't to deny that there aren't good points in there (there are some very good points that people looking for a DBMS should know about), but it is to deny that it's on topic.

  • First, I'd like to say that DBI itself is very cool, and I find it really useful.

    I read the book as soon as it came out several weeks ago; I was anticipating its release very much. I skimmed most of it, though, as it's kinda lightweight. The first 50 pages deal with flatfiles.. blah. Out of 330 pages, the last 140 of them are appendix -- which is the perldoc pages that you can get a more up-to-date version (and quicker access) of online.

    Also, I think it's weird that they'd spend 50 pages on (non-DBI) flatfiles, then only like 125 (excluding appendix) on DBI.

    I use DBI/MySQL at work for CGI/database interfacing. I haven't looked at the book for weeks, and it's on the bottom of my pile of books. Since I gave such a bad review myself, I thought I'd find some links to look at. People already mentioned Mark-Jason Dominus' tutorial, which I agree is a nice intro. I tried not to repeat links others gave: Also, if you do web-database stuff, check out Apache::DBI, which does the obvious. Okay, sorry to be so negative.
  • Regarding transactions: well, HTTP is stateless, innit. The only way you're going to lose integrity with a half-done transaction... [snip]

    Bob: a lot of work has gone in to being able to maintain session state across stateless HTTP request/response calls. This is a feature of ASP, JSP, PHP, etc. A transaction can certainly start on one page and end on another, and in the meantime, the client can experience communication problems, change his mind, Windows 98 could blue screen :-), etc.

    --jb
  • perldoc -t DBI > DBI.txt and you've got yourself an (almost as good)O'Reilly book :)
  • MySQL has its flaws, but I agree that this is not one of them. We use it as the database backend for our webserver where I work, and this little feature saved me a bunch of programming when I was trying to get a date input form working. The user could select the day, month, and year from dropdown boxes, but thankfully, MySQL would roll over the year or month if the user had made an error. If it wasn't what they actually wanted, they could go back and fix it, but I was glad I didn't have to error check each month...
  • One db I've never seen mentioned here on /. and deserves mention, is Frontbase [frontbase.com]. They offer a free version (though not open source), which does support transactions, stored procedures, foreign keys, permissions, etc (not sure about cross database joins :-) ) and is fast (the 0.5s quoted above for an insert/commit seems like an awfully long time). They also offer some value added features if you're willing to pay. One of those includes import/export (which sux cause we use the free version), but they do give away a developer version which is totally functional (and suffices to do import/export). We've been using it for almost a year, and they mean it when they say zero down time.

    Now I'm not a 'serious' db programmer, but I think FB should be checked out.

  • Um ...has Slashdot ever run a unfavorable book review before? I really want to know. It seems like every review that comes out just trumpets the virtues of the latest manual that comes down the pike -- more often than not from O'Reilly. Problem is, I make a point of skimming a lot of these books for myself, and in spite of what the reviews here say, they're *not* uniformly excellent. Some are, to be sure, but others... yechh.

    Further, in addition to being about as negative as advertising copy [that is, not at all], they're also uniformly shallow. I guess there isn't anything deep to be said about a lot of this material (though a review of the existential angst and ennui in a data patterns book could be pretty funny), still a lot of these just feel like a rehash of the table of contents. Surely we can do a little better than that.

    I know, I know, the "right" thing to do, if I'm so disappointed in the reviews, would be to offer some myself (or encourage others to do so -- I'm not saying I'm necessarily the one that can fix the problem). Fair point, but the one thing I give you is that you consistently read the books before I get a chance so that doesn't feel like an option here.

    I dunno. I guess I'm just asking for some variety. I love O'Reilly books too, and think well of most of the many I've read (but not all! e.g. the MySQL one... damn that was lousy), but it's hard to take the reviewers opinions seriously when they like *everything* they write about. Maybe we can run some reviews of "...For Dummies" books as counterpoint or something, or get multiple *contrasting* reviews each time around. As it is, the reviews are barely worth reading -- I could just thumb through an ORA catalog of upcoming titles to see for myself what you're going to love next...



  • What I don't see is how flipping databases and mixing databases in your joins "kills much of the usefulness of having transactions".
    I'm not the original author, but...
    If you have data in two database on the same server (and a lot of us do, for a lot of good reasons) then you want (read need) to be able to access both dbs in the same transaction.
    If you have to have two conntections and feed the data between them, then you are running TWO transactions, and loose your integrity guarantees.

    INSERT db_one.table_one
    SELECT max(id) from db_two.table_two
    becomes
    [Tran1] $max_id = SELECT max(id) from table_two
    [Tran2] INSERT table_one VALUES($max_id)
    and you loose your consistency.

    Cross database selects are critical to handling consistency across databases.

    --

  • have to find out how to print man CGI
    You want to try some setting on nroff/troff/groff. The exact settings tends to vary with OS.
    On Solaris 2.6, I use the following:

    cd /opt/perl5.004/man/man3
    nroff -mansun CGI.3 > ~/mancgi

    I'm afraid I don't have a linux box to try on.
    HTH.

    --

  • Good book, but only moderately more info than's available on the web. But if Tim and Alligator get some money out of it, great. They're both active on the dbi-users listserv which is very good and has helped me many times in less than a year. Somewhat related: I've used this one in conjunction with Lincoln Stein's 'Programming With CGI.pm'. For me, Linocln's book does give more than I can find on the net -- either that or it's just organized better. On the other hand, I haven't found a good CGI.pm mailing list. DBI is a great tool though. I've thrown together dozens of database tools with it in fairly short order.
  • I just spent a few hours looking over the book. After finishing it, I felt it was far too short.

    The first part, on flat file databases, was really very good. Those chapters explain elegantly the pros and cons of flat files, and explain how to program with Perl if you wish. However, the relation to DBI was not very strong.

    The second part, on Berkeley DB and GDBMs, was not quite so elegant. It might have tried to describe in more detail the fundamental differences between hashed databases and flat files on the one hand and RDBMs on the other. And then it could have offered some suggestions on which to use. Also, it had to cover a couple of DBI implementations at that point, and became a little confusing.

    The last part, on ODBC, seemed full of wise ideas, but also was too short. Longer examples with more implementation details are needed here.

    Finally, I would have like some long examples of applying DBI to various databases. For example, several comments here characterize MySql, and I'd like to hear more from the authors about using it in real, longer examples.

    So I do hope O'Reilly will come out with a second edition, updated if we get new versions of interfaces, and with twice as many pages, giving some real, long examples.

    Still, I have many first editions of O'Reilly books, and they have stood the test of time. So I wouldn't hesitate to buy the book if I were programming with Perl and databases. As it is, it could easily save you a lot of development time, and put you in touch with some good resources to solve your problems more easily.

  • This book has been around for awhile now, and I've long since gone through it. Actually I'm expecting my copy of OOP Perl to arrive tomarrow and am looking forward to reading something new.

    My biggest gripe with the book is it gears up too slowly and ends too soon. If you already know what a database is, and how SQL works, skip the first half of the book. If you are looking to learn about the nuts and bolts of how use/setup a specific DBD, you will need to look somewhere else (the man pages are a better source here.)
  • Timothy, I am Adolf Hitler...

    Your puckered little anus is European Jewry...

    Get ready for the Anal Holocaust you little bitch!

    YEAH!

  • I was trying out DBI with Oracle before this book came out, and once I got my hands on it, I
    quickly devoured it in a matter of hours.

    Overall, it was a good giude to get started, but I found that it was a bit short and could have had
    a bit more depth and advanced topics.

    For example, I was having trouble with updates and building a sql statement with lots of quotes. The
    book didn't cover this enough, but I was finally able to work it out by reading through the perl dbi doc.

    So, it's a good start, but the dbi perldoc is still needed for a more detailed examples.
  • Aha! Gotcha. Yup, that makes sense. Thanks.

    ("D'oh", too :)

    Not much one can do to work around that, is there? :(

    Still, it's the seemingly-synchronous writing stuff that's slowing me down that's worrying me most atm.
    ~Tim
    --
    .|` Clouds cross the black moonlight,
  • Like everything else, both MySQL and PostgreSQL have their advantages and disads.

    MySQL is fast with easy backups and outer joins, but none of the durability stuff. PostgreSQL is slower (not slow), but no outer or cross-db joins.

    Know what -- I'll take either one over Sybase or Oracle any day of the week. I've worked with all of them and keep going back to opensource for a reason.

    Two current clients of mine are using MySQL for their web-interactions, feeding the data from a PostgreSQL database. In one case, we went to PG because Sybase install has been down for two weeks (during development, thank ghu) and Sybase can't figure out why.

    One of these companies is even making extentions to PostgreSQL and handing them back to the opensource community as a thanks. (BTW, any good db-programmers looking for a job adding even more features to PostgreSQL? )

    If you want a feature in opensource you can (1) write it yourself, (2) pay someone to write it, (3) wait for the existing developers to do it. With a commercial product, you can #3 period. W're opting for #1 and #2 since the devlopers are working on other stuff -- end result, even more functionality faster.

    As far as cross or multi-database joins (not transactions), think about a proxy server that maintains durable connections to each DB and handles the join for you. It worked for us.

    -coranth [mailto]

  • I agree that Slashdot reviews are generally positive, but I wouldn't place blame on Slashdot for that. In fact, I wouldn't blame anyone. Put yourself in the shoes of the reviewer. If you picked up a bad book, would you want to read all the way through it just to fully appreciate how bad it was? I certainly wouldn't. But I wouldn't want to submit a review of a book I hadn't read throughly. The causality of the issue lies more in that people don't want to review bad books than that Slashdot wants to promote ORA (which does publish many good books).
  • I don't know. I sort of think that Slashdot should have an editorial obligation to run a more diverse selection of reviews. I understand that no one wants to read bad books, nevermind examine them enough to write reviews. But that only exacerbates the problem here -- tastes vary, and no matter how good or bad some title is, *someone* out there is going to like it enough to want to write about. If we just run every single positive review that comes in, then it's hard to take any of them seriously -- at least for me it is.

    Maybe the solution would be to have a staff critic, or a commission for published reviews or something. Some incentive, in other words, to speak up about a title even if it wasn't that great. I have no idea if Slashdot has the budget to take on a (part|full) time staff critic, but I think that doing so could bring in quite a bit of credibility to this department.

    I'm not really assuming that Slashdot is trying to push ORA books, even if it comes across that way. But publishing a variety of reviews meets several needs -- for one thing, it highlights titles that should may be avoided, and more importantly it raises the believability of all reviews when it is seen that the site is capable of saying this or that book was just plain bad, or even mediocre or had a certain flaw or sucked excepot for so-and-so or... you get the idea.

    Variety, variety, variety. Spice of life, doncha know, and we don't have neough of it around here. I'll belabor no further :)



"Virtual" means never knowing where your next byte is coming from.

Working...