Programming the Perl DBI 59
| 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
- Introduction
- Basic Non-DBI Databases
- SQL and Relational Databases
- Programming with the DBI
- Interacting with the Database
- Advanced DBI
- ODBC and the DBI
- DBI Shell and Database Proxying
- DBI Specification
- Driver and Database Characteristics
- ASLaN Sacred Site Charter
Re:MySQL... (Score:1)
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!
Finally... (Score:1)
DBI resources (Score:4)
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.
Thoughts on the book.... (Score:3)
Re:MySQL... (Score:1)
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.
additionally ... (Score:1)
Re:MySQL... (Score:1)
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...
Re:MySQL... (Score:1)
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
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.
Re:slashdot and o'reilly (Score:2)
Re:MySQL... (Score:3)
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.
--
Re:MySQL... (Score:1)
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.
Where to get O'Reilly's books cheap! (Score:1)
Re:Thank God (Score:1)
Re:MySQL... (Score:1)
Re:MySQL... (Score:2)
"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
--
Light mode (Score:1)
<FONT COLOR="#FFFFFF">Book Reviews</FONT>
Re:Oracle (Score:1)
Re:slashdot and o'reilly (Score:1)
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.
Re:MySQL... (Score:2)
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.
--
This comment was brought to you by And Clover.
Should Feb 31 be valid date ? (Score:1)
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.Re:MySQL... (Score:1)
--
E.
DBI online resources are better (Score:1)
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?
Re: (Score:1)
Re:Thoughts on the book from someone used to DBI (Score:1)
Re: (Score:1)
Re:You can't write an OS in Perl so ... (Score:1)
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.
Re:Thoughts on the book.... (Score:2)
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.
Re:MySQL... (Score:1)
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.
Re:DBI resources (Score:1)
Mike Roberto (roberto@soul.apk.net [mailto]) -GAIM: MicroBerto
Agreed.. (Score:1)
Re:MySQL... (Score:1)
I got it for half price yesterday! (Score:2)
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.
Re:DBI resources (Score:1)
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)
Re:Light mode (Score:2)
1/2 price books - cheap O'reilly books , sometimes (Score:1)
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
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!
timothy
buying this book is gratutious (Score:1)
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!
Re:MySQL... (Score:2)
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.
--
No, they're not :) But on the other hand ... (Score:1)
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
Re:Finally... (Score:1)
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 :).
Book Publishers (Was Re:Finally...) (Score:1)
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!
Re:MySQL... (Score:1)
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.
disappointed.. (Score:1)
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:- Interview with the authors [oreilly.com]
- DBI-users archive [mail-archive.com]
- Old DBI-users archive, but w/index [bitmechanic.com]
- Positive review [perl.org] by perl.org (duh..)
Also, if you do web-database stuff, check out Apache::DBI, which does the obvious. Okay, sorry to be so negative.Re:MySQL... (Score:1)
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.
--jbRe:Thoughts on the book.... (Score:1)
Re:Should Feb 31 be valid date ? (Score:1)
Frontbase (Score:1)
Now I'm not a 'serious' db programmer, but I think FB should be checked out.
Problem with Slashdot book reviews (Score:4)
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...
Re:MySQL... (Score:1)
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.
--
Re:DBI resources (Score:1)
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.
--
Re: Programming the Perl DBI (Score:1)
Re:Thoughts on the book.... (Score:1)
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 is an oldie... (Score:2)
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.)
Re:No, they're not :) But on the other hand ... (Score:1)
Timothy, I am Adolf Hitler...
Your puckered little anus is European Jewry...
Get ready for the Anal Holocaust you little bitch!
YEAH!
Only moderate depth on DBI (Score:1)
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.
Re:MySQL... (Score:1)
("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
--
Re:MySQL... (Score:1)
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]
Re:Problem with Slashdot book reviews (Score:1)
Re:Problem with Slashdot book reviews (Score:2)
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 :)
Could it be the.. (Score:1)