Code Camps and Revisiting a Common Theme

Adam Machanic — Sat, 29 Sep 2007 19:33:00 GMT

Today I gave two talks at New England Code Camp 8. A fun experience as always, and for those of you who were in my talks and are looking for decks/code, please see this post and this post from when I did slightly different versions of the same talks earlier this year as MSDN Webcsts. I am not quite ready to publish the decks I used today.

But the topic of this post is not so much the code camp as an observation about what I saw there. Recent posts by both of our resident Andys (Kelly and Leonard) share the theme of organizations treating their database staff as next-to-worthless. And developers, in general, seem much more interested in other facets of development than all of that "database stuff."

Today's code camp proved this once again; my two talks were both quite lightly attended, even though I was talking about important issues around data security and exception handling--things that any developer working with data should get. Perhaps it's just me, but the evidence says otherwise: after my talks I peeked into a few others and found a standing room only session on Silverlight and a session on LINQ to SQL that had a comparable number of attendees to what I'd had.

Why is it that data, while the foundation of any business application, is not a draw to the developer masses? How can we ignore the data and instead focus on creating spiffy new UIs (to display flawed data, no doubt)? Perhaps data seems easy--if you know how to write a query and set up an ADO.NET connection, that's all you need, right? Or perhaps data is just someone else's job--just let the DBA or database developer handle it and display anything that comes back, flawed or not. It's not your problem, you're a UI developer. But everyone can't be a UI developer, can they? Someone has to take control of the data.

Bad data can and does lead to project failure. If you're a UI developer you're going to get canned just as quickly as the DBA if you're project is no longer being funded--so if your UI displays bad data, you are just as guilty as whomever designed the database that returned it! If you're a business tier developer, you are just as responsible for data validation as the database developer!

Alas, if you're reading this post you're already one of the converted. This is SQLblog.com, so you obviously care enough about your data to read up on it a bit more. But as developers who know the value and importance of data, it is our job to spread the data gospel. Data issues around security, validation, and performance are every developer's responsibility.

Log Buffer #21: A Carnival of the Vanities for DBAs

Adam Machanic — Fri, 01 Dec 2006 11:00:00 GMT

Hello, there! You’ve somehow managed to navigate your way through the blogosphere and into the 21st edition of Log Buffer.

It’s fitting that this is the 21st edition, because that just so happens to be the legal drinking age here in the United States. And the folks over at Oracle sure need a drink or three this week. Computerworld’s Jaikumar Vijayan reported on a study showing that Oracle has more security flaws than SQL Server. And over at IT Toolbox, Chris Eaton was nice enough to link us to the actual study, and in his post also mentioned that a security firm called Argeniss had promised to release one Oracle security flaw every day this week.

The Oracle Security Blog's update on the topic, posted a few days after Chris's post, reveals that the week of disclosure is not happening -- at least, not quite yet (Argeniss apparently temporarily "suspended" the project). But don’t worry! If you just can’t live without that sticky-sweet feeling of bliss that accompanies finding a particularly nasty hole in someone else's software, head on over to Eddie Awad's blog, where you can learn how to snarf a dangling cursor. And now I will sit back and watch as my inclusion of that phrase gets this post banned by all of my readers' corporate indecency filters. Snarf on!

For those ~~serve up your customers' data to hackers on a silver platter~~ live-on-the-edge types in the audience who have time to worry about anything non-security-related amidst all of the concerns being raised, there were a few interesting tidbits posted this week. Edgar Hoover dished up some tips on using functional indexes in 9i. And Lucas Jellema showed us a way to avoid long strings of UNION ALL'd queries when trying to create "dummy" data. But if you're running on Linux, good luck using these tips at all! Brian Aker clued us into the fact that most installations are incredibly instable and that there just aren't enough experts around to fix the problems. "Free" operating system. Expensive consultant needed to fix it. What doesn't add up here?

For better or for worse, life in the MySQL camp was not nearly so exciting this week. Ronald wrote an interesting post about Pluggable Storage Engines, but to me it sounds like it's just metadata management given a snazzy new name. And over at the So What Co-operative blog, Jeff Hunter got some flack because he implied in a post that MySQL isn’t ready for prime time (i.e., no mission critical apps). For shame, Jeff! Rounding things out was a good post by Kevin Burton all about Ethernet latency and how it can affect database performance.

It's life as usual for the PostgreSQL and DB2 crowds. Josh the PostgreSQL lead posted not one, but two articles containing performance tips. And Willie Favero pointed out the availability of a couple of new IBM Red Books: One covers the oh-so-popular topic of SOA, and the other is all about LOB data.

Which brings us nicely around to the world of SQL Server. You didn’t think I'd forgotten, did you? A good post came from Denis the SQL Menace, who brought to light a not very well publicized feature of SQL Server 2005: the ability to tell the engine to update statistics asynchronously. But this week's highlight came from Mladen Prajdic, who discussed an interesting way to get high-precision performance metrics in SQL Server, via a few SQLCLR routines. The only problem with Mladen's technique is that it appears to only work on a single thread at a time. Still, it's definitely an interesting technique to consider, and a great SQLCLR sample to keep around.

In the SQL Server tools department, we were informed by Bart Reed of Red Gate that SQL Prompt 3 might actually be coming some day! I was in the beta for this product, and I have to say that it's looking pretty interesting -- I definitely hope that some day is sooner rather than later, so get back to work and stop blogging, Bart! Luckily, we don't have to wait for Red Gate to get some enhancements to SQL Server Management Studio. Paul A. Mestemaker II provided detailed information on how to add a custom report to Management Studio in SQL Server 2005 SP2. And low and behold, Jasper Smith has already published a very useful report, a recreation of the much-missed Taskpad View from Enterprise Manager.

Since not everything in our industry is product-dependent (well, it's not supposed to be), let's not forget that database design is a more or less transferable skill -- at least, if you have any clue about what you're doing. The first consideration is usually data types, but as Tom Kyte pointed out, some people just don't get the difference between strings and all of those other newfangled types (as an aside: it was an Oracle person… should we be surprised?) Apparently it was character types vs. the world week in DB2 land as well, because Craig Mullins also weighed in with a post on the topic.

To close, I'd like to point out that despite Eddie Awad's concerns about laziness, I believe that all of the best computer professionals are lazy at heart. That's why we use macros, create shortcuts, and script/automate everything. We don't like working any more than we have to! And that is why I'll leave it to not-so-lazy people -- like Joe Celko -- to come up with information on techniques such as an additive congruenital method of generating values in pseudo-random order. Uh, yeah.

So with pseudo-randomness in mind, I bid you, kind reader, adieu. And remember to watch out for those pesky dangling cursors! There's no worse feeling than coming in on a Monday morning and settling down with that first hot cup of coffee, only to discover that you've been snarfed over the weekend.

Adam Machanic : Security

Code Camps and Revisiting a Common Theme

Log Buffer #21: A Carnival of the Vanities for DBAs