Welcome to the 102^nd edition of Log Buffer, the weekly review of database blogs.

Since it was DB2’s 25^th birthday this week, as Anant Jhingran reports, let’s start with it.

From ZDNet this week came a story that IBM was considering the open-sourcing of DB2 — big news, naturally, whether true or not. Matthew Aslett of 451 CAOS Theory says, Open source DB2? I don’t think so, suggesting that it was merely theorizing on the part of one IBM executive, and hype on the part of ZDNet. “Then of course,” Matthew continues, “there is the issue of why IBM would open source DB2. Where is the business driver? Despite solid competition from Oracle and Microsoft, the company is doing pretty well with DB2 as it stands, thanks very much, and open source databases have had minimal impact on the established vendors.”

Matt Asay of The Open Road likewise comes down on the uh-uh side of this. “It was . . . no surprise to see IBM quickly follow up ZDNet’s article with a blunt statement: ‘IBM has no plans to open source DB2.’ Of course it doesn’t.  . . . The day that it needs DB2 to undermine Oracle’s database, however, we may see IBM making a similarly bald statement…in the other direction.”

On An Expert’s Guide to DB2 Technology, Chris Eaton offers some news on DB2 videos, including ChannelDB2’s video tutorials, IDUG’s video competition, and a funny video from IBM on the making of a “viral” industrial video. Such as itself.

On to MySQL now. Keith Murphy made his debut on the Pythian blog this week, with a link to some video tutelage of his own — his presentation to the Boston MySQL Users Group on backups. Jay Pipes also offers the slides for his address on Join-Fu: The Art of SQL (I and II). (I rarely cover presentation materials when I do Log Buffer, but these ones of Jay’s looks fantastic.)

Mark Schoonover reports that Keith’s and his 2008 MySQL Magazine survey is officially closed, adding, “Now the fun begins compiling all the data and pretty charts made. We’ve had 432 responses!”

Baron Schwartz of xaprb describes how to write a lazy UNION in MySQL. No, it doesn’t deal with posting a complaint about undefended job benefits. Baron explains: “Something occurred to me a couple of weeks ago: why not write a UNION that stops executing as soon as one part of it finds a row? Then you can UNION to your heart’s content and not incur the overhead of that second lookup unless you need it. For lack of a better term, I’m calling this a lazy UNION.”

(more…)

Welcome the the 101^st edition of Log Buffer, the weekly review of database blogs.

This edition was originally claimed by Ward Pond for his SQL Server Blog. Unfortunately, Ward is, in his own words, “dealing with the aftermath of a burst appendix,” which is a very good reason not to spend your time at the computer. Ward, heal up soon! We’ll see you on LB before too long.

In lieu of the normal Log Buffer, I throw it open to our readers. Please leave a comment mentioning your favourite database blog items from the week that was, and anything else you care to say about them.

LB will be back to normal next Friday. See you then!

Log Buffer, the weekly review of database blogs, is 100 editions (and almost two-years) old today! Lewis Cunningham has returned to LB to publish The Big 100^th edition of LB on An Expert’s Guide to Oracle Technology.

No speech, but I would like to thank Log Buffer’s readers and especially all of Log Buffer’s editors for making LB a worthwhile and fun stop in the database “blogosphere”. It’s very easy to see why LB editors are successful in what they do — they are consistently enthusiastic, diligent, and adaptable. And I enjoy working with them.

Okay, okay — I can hear the orchestra starting to play me off, so let’s get to it. Here’s Lewis’s Log Buffer #100.

Welcome the the 99^th edition of Log Buffer, the weekly review of database blogs.

Since PGCon recently happened right here in Ottawa, let’s start with some posts about it, and about PostgreSQL. Josh Berkus came to the conference with his Database Soup. It sounds like he enjoyed himself: “So, that’s pgCon. It was exciting and fun. All of you PG geeks who missed it should be kicking yourselves about now, and putting in budget requests for next year.” He has day one highlights; day two highlights, and also some photos from the conference.

On Tending the Garden, Selena Deckelmann (who knows a thing or two about Postgres conferences) has her PGCon review, with links to conference webpages.

Robert Treat of zillablog also has his take-aways. “The biggest thing to come out of this past week to me was recognition of the continued growth of the postgresql community. With a number of regional conferences springing up over the past year, I wondered if PGCon would be able to match the experience from last time, and was happy to see that it far exceeded it. . . . One thing I noted was that we have a very large presence of Postgres in Ottawa, I think larger than what we had at PGEast for the Baltimore/Washington Area.”

On Greg’s Postgres stuff, Greg Sabino Mullane has an item on verifying master-slave replication with check_postgres.pl, a montoring script for Nagios and other systems.

Hubert Lubaciewski of select * from depesz; looks at different approaches to counting the number of distinct elements, such as distinct sessions per day.

On An Expert’s Guide to Oracle Technology, Lewis Cunningham examines the recent news of the worlds largest database running on Postgres. How large? 2 Petabytes! “Let’s put that in perspective,” writes Lewis. “1 petabyte is 1,000,000,000,000 bytes. Yahoo has two of those. . . . [They use] this database to analyze the browsing habits of its half a billion monthly visitors. How would you like to tune those queries?” Lewis also notes that this is not the plain-vanilla PostgreSQL that you or I would download and run on our website box.

There are conferences on the horizon of the Oracle world too. Dan Norris reminds us that ODTUG is just around the corner. That’s the Oracle Developer Tools User Group’s Kaleidoscope 2008 event, taking place in mid-June in New Orleans.

Gareth Roberts of In Depth Apps announces the call-for-papers of the New Zealand Oracle Users Group’s (NZOUG) 2008 conference, coming in October.

In other Oracle matters — Chen Shapira, just a simple DBA on a complex production system, has some thoughts on cumulative distribution. “How do we calculate Cumulative Normal Distribution? This means calculating the probability that a random variable from a normal distribution, will end up equal to or less than X.”

(more…)

The 98^th edition of Log Buffer, the weekly review of database blogs, has been published on Jeff’s SQL Server Blog.

Log Buffer is a shared project of the DBA blogging community, so you’re welcome to edit and publish an edition yourself. LB’s 100^th anniversary edition is still up-for-grabs (and there’s plenty of room besides that), so read the Log Buffer homepage and the guidelines, and then email me.

Here’s Jeff Smith’s Log Buffer #98.

The 97^th edition of Log Buffer, the weekly review of database blogs, has been published on Brian “Krow” Aker’s Idle Thoughts.

We have Jeff Smith and Ward Pond standing by for two upcoming editions. And if you’d like to contribute, make yourself known in the DBA community-at-large (and have some fun in the process), you too can do Log Buffer! Read the homepage and send me, the Log Buffer coordinator, an email.

And now, Brian Aker’s Log Buffer #97.

Contemporary software engineering models include many loosely-defined layers. Database developers might help with other layers, but for the most part a database administrator’s domain is the persistence layer.

• Presentation


• Application


• Business Logic


• Persistence (also called Storage)

The Daily WTF has an article on The Mythical Business Layer makes the case for not separating the business layer and the application layer:

A good system (as in, one that’s maintainable by other people) has no choice but to duplicate, triplicate, or even-more-licate business logic. If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL in the database and have some client-side code to validate it was entered as seven digits. If the system allows data entry in other places by other means, that means more duplication of the Account_Number logic is required.

It almost goes without saying that business logic changes frequently and in unpredictable ways. The solution to this problem is not a cleverly coded business layer. Unfortunately, it’s much more boring than that. Accommodating change can only be accomplished through careful analysis and thorough testing.

I will call this merged business/application layer the “functional layer.”

The serious scaling requirements posed by most applications these days call for partitioning, clustering, sharding or some other term for “dividing up the data so it does not become the bottleneck”. Enter the “architecture layer”.

“Wait a minute,” I hear you asking. “Isn’t that just the persistence layer?”

Yes and no. To me, there’s a difference between the storage and the architecture of said storage. The database schema for storing a user profile is a persistence layer issue. Figuring out which database instance to go to is an architecture layer issue.

This is an important distinction for me. Many folks are coding the architecture layer directly into the functional layer. A “save_profile()” API function might call an ORM to deal with the persistence, or it will have MySQL (or other database) connection handling and queries. However, the database will grow, and at some point you will find yourself wanting to split the data [more].

This type of information, like the presentation layer, needs to be separate. Why should the application care whether save_profile(’Sheeri’,'hair color’,'blonde’) accesses database1 or database2? More importantly, why should there be major code changes to the functional layer if the architecture changes? Just like no functionality has changed when you change your website color from blue to red, there is no functionality change when you go from splitting data between 2 database servers to splitting among 3, or 10.

For me, the persistence layer is about how the data is stored. Which, explicitly and for the record, I also believe should be separate from the functional layer — if you store hair color and eye color in one table or 2, the functionality of the application has not changed; all that’s needed is a change in how that data is stored and retrieved.

The architecture layer is all about where the data is stored. Early forms of the architecture layer are configuration files, though most would not call that a “layer”. Database administrators should be able to change the architecture of the database system without requiring mucking about in the application’s functional code.

Thoughts?

This is the 96^th edition of the weekly review of database blogs, Log Buffer.