Biographical Information
Kevin Kline
Technical Strategy Manager for SQL Server Solutions, Quest Software
|
Kevin Kline is the technical strategy manager for SQL Server Solutions at Quest Software. A Microsoft SQL Server MVP, he is a founding board member of PASS and the author of several books, including SQL in a Nutshell (O'Reilly & Associates). Kline is a top-rated speaker at industry trade shows and has been active in the IT industry since 1986. For information about Quest Software, go to www.quest.com
|
|
Third-party applications are a very important part of the IT landscape. Many of us have faced the common dilemma of trying to decide whether to build or buy that next important application our organizations need. (By the way, I'm talking about smaller, specialized applications like an inventory management system for the company warehouse, or a practice management system for a doctor's office. I'm not talking about the huge and incredibly sophisticated ERP systems like SAP and Oracle Financials.)
The idea of "SQL Server in the cloud" is all the rage as I write this article. Many SQL Server experts already predict the demise of the IT data center and a complete upending of the current state of our industry, in which large enterprises can spend millions of dollars on SQL Server licenses, hardware and staff. I have to admit, when I first heard about this idea, I was ecstatic. What could be better for an enterprise than to have all the goodness of a SQL Server database with none of the hardware or staffing issues? However, on deeper examination, there is much about which to be cautious.
In my many years on the board of directors of the Professional Association for SQL Server (PASS), I frequently exhorted our members to strive for individual achievement and personal excellence. One of the best paths for many SQL Server professionals is through certification, especially if they lack years of demonstrated on-the-job experience. However, certification only paints half the picture. While it might demonstrate, at a minimum, that you passed a test (or several tests) about the database technology, it tells nothing about your standards for good conduct.
Microsoft SQL Server's relational engine has offered new instrumentation that improves by light years with each new release. The introduction of Dynamic Management Views (DMVs) in SQL Server 2005 provided a much-needed equivalent to Oracle's long-standing and capable V$ and X$ system views. SQL Server 2008 has provided another dramatic improvement to its instrumentation with Extended Events (also known as XEvents) that promises to offer even greater opportunities to tune, trace and troubleshoot the inner workings of a SQL Server application. All of this stands in stark contrast with the anemic instrumentation offered in SQL Server Analysis Services, Microsoft's wonderful multi-dimensional data repository that is a free feature-set within the SQL Server product.
At a rather muted Microsoft TechEd in Los Angeles in May, the crowds were diminished and the educational content was slimmed down. In the past, SQL Server sessions were so abundant that you'd have trouble choosing which of several you might want to attend. This year, the state of the economy was reflected in many ways, including the one, or, in just a few cases, two sessions per time slot allotted SQL Server professionals. Despite the low ebb, the Microsoft SQL Server team made an exciting announcement about the upcoming availability of the SQL Server 2008 R2 CTP (Community Technology Preview).
In my last column (published in the February e-edition and the March print edition of DBTA), I reviewed the overall coding landscape for SQL Server with special focus on LINQ to SQL, a new technology introduced by Microsoft in late 2008. LINQ to SQL promised to make developers' lives much easier by allowing them to focus on writing programs in their favorite Visual Studio language and letting LINQ to SQL write all the Transact-SQL code. The problem is that LINQ to SQL writes very bad Transact-SQL code.
Implementing PBM in your environment will probably require more than just a few superficial changes.
In a two-part article over the next two months, I'm going to address an important issue for the SQL Server community: the future direction of coding for SQL Server, as directed by Microsoft. I'll start by telling you a bit about the current situation with writing code on and for SQL Server, and, in the next installment, talk more about the ramifications brought on by the current coding environment.
SQL Server has supported VLDBs (very large databases) for some time now. Back in the SQL Server 2000 days, I recall hearing multi-terabyte databases were unusual but doable. Now, they are commonplace, while databases in the hundreds of terabytes inhabit the part of the map that says "there be dragons." While VLDBs are quite common on SQL Server today, highly scalable systems that can be flexibly extended in the same fashion as Oracle/RAC are less so. So, how do you design a highly available architecture for SQL Server if it's not like Oracle/RAC.
If you haven't paid attention to the new social media, you're doing yourself a disservice. Just as email was a game-changer in the 1980s and the internet revolutionized society in the 1990s, social media is making a huge impact on the way people work and interact today. Personally, I was skeptical about social networking until some good friends persuaded me to give it a trial run. It seemed like a great way to dither away some valuable time, but I didn't see the business value in the whole proposition until I tried it.
One thing I really enjoy about the SQL Server community is its vibrancy. I'll give you details on the SQL Server community's explosive growth in a moment, but let's start by comparing Microsoft SQL Server's user community with those of other significant database platforms.
If you spend any time at all reading IT trade journals and websites, you've no doubt heard about the NoSQL movement. In a nutshell, NoSQL databases (also called post-relational databases) are a variety of loosely grouped means of storing data without requiring the SQL language. Of course, we've had non-relational databases far longer than we've had actual relational databases. Anyone who's used products like IBM's Lotus Notes can point to a popular non-relational database. However, part and parcel of the NoSQL movement is the idea that the data repositories can horizontally scale with ease, since they're used as the underpinnings of a website. For that reason, NoSQL is strongly associated with web applications, since websites have a history of starting small and going "viral," exhibiting explosive growth after word gets out.
If managing your corporate data for the long term isn't currently on your mind, it should be, and in several different ways: cost, performance, business continuity, and compliance. First, let's talk about cost and performance. You want to manage your database infrastructure so it can support your growing data needs within budget, while providing acceptable performance to your users. SANs (storage area networks) have enabled us to meet these contradicting goals over the last decade, and, as I mentioned in a previous column, SAN vendors are offering innovative new technologies to push on-disk storage even further. Some interesting new strategies also are helping organizations achieve a more balanced mix of cost versus performance through the use of "tiered storage."
When a new version of one of my favorite products ships, one of the first things I do is open the online help and read "What's New in This Release." I usually look at the new features from two levels. First, I don't install much software that I don't use, so I'm always keen to see what the new features can do to make my life better, my time more productive, my computer faster, my kids behave better, and so forth.
Compliance is one of the most interesting elements of any data management plan - it's a microcosm of evolution in action. When many of the laws that impacted data retention were first enacted, business wasn't collecting a lot of information. Now, data collection happens everywhere. And, as citizens have come to realize that more and more of the information about their daily lives is recorded, they demand their governments provide privacy and protection from misuse of that data.
After the misery that was 2009, most of the SQL Server users I talk to are happy that 2010 started in languid fashion. Not that there isn't a lot of work to do; on the contrary, there's more work than ever. However, the long hours and multiple projects of 2009, compounded by freezes in all levels of spending, raised the general stress level to unhealthy heights. With the new year, stress levels dropped significantly, and many IT leaders see signs of improving prospects. What does that bode for 2010? I have a couple of predictions, though I doubt they'll surprise many people.
If you've read the IT press at all these days, you know that SQL Injection (SI) attacks are very common and can be devastatingly effective. In fact, SI attacks-equally easy to execute against Oracle, MySQL, IBM DB2, or Microsoft SQL Server-are among the most common hacks on the Internet today. If a web application runs a relational database on the backend, it can be subject to an SI attack, which ironically, is among the easiest web hacks to prevent.
In this season of recession and financial meltdowns, a common question seems to be, "How big is ‘too big to fail'?" Titans of the financial industry made big bets with lots of risk and, when they didn't pan out, American society overall has to pay the price. But, that aside, the very scale of our financial system, by just about every metric, has reached amazing heights, be that number of financial transactions per second, number of traders, number of funds traded, amount of money changing hands—you name it. This might seem like a tangent to the point of databases in general and SQL Server in particular, but there are actually quite a few similarities in my mind.
Listen to a group of database professionals talk for awhile and someone will eventually bring up the topic of data deduplication. Data deduplication is a means to eliminate redundant data, either through hardware or software technologies. To illustrate, imagine you've drafted a new project plan and sent it to five teammates asking for input. That single file has now been reproduced, in identical bits and bytes, on a total of six computers. If everyone's email inbox is backed up every night, that's another six copies backed up on the email backup server. Through data deduplication technology, only a single instance of your project plan would be backed up, and all other instances of the identical file would simply be tiny on-disk pointers to the original.
One fall semester many years ago, I was a university freshman. Actually, I was anything but "fresh." I was dumb enough to think that 8 a.m. was a wonderful time to attend Economics 101. After staying up until the wee hours most every night, the "dismal science" took on more than one meaning as I set my clock just early enough to get to class on time. Along with 30 other very naïve classmates, I staggered into class and did my bleary-eyed best to focus on the lessons at hand. There were lots of Greek compound words and lots of graphs. I learned, for example, that the word economics derives from the Greek "oikonomikos," which means, approximately, "death by slidedecks" and, specifically, "house" (oikos) and "management" (mikos). I barely survived the experience and never took an 8 a.m. class again. Imagine my surprise, then, when a lesson I'd learned (and promptly forgotten) all those years ago jumped back into my consciousness late last year.
I was once asked what I thought Microsoft's overall product trajectory for SQL Server was, in light of Oracle's rather obvious trajectory of acquiring multiple application vendors who will, in turn, deploy more and more of their applications to the Oracle database platform. To be honest, I had a little difficulty perceiving a clear and concise strategy statement for the sort of work going on in Redmond. I could see a lot of great features being developed. And I knew the SQL Server development team had developed a lot of new "plumbing" with each new release - features like Service Broker and Extended Events and exponentially more robust capabilities in the Analysis Services product lines. But the strategy itself was veiled and, since Microsoft wasn't explicitly telling us what the grand strategy was, I had difficulty putting my finger on it.