Voice of the DBA

Category: Editorial

  • Project Hekaton

    If you haven’t heard about Hekaton by now, you should think about reading up on it. There’s some information from TechNet, a keynote video, and more. Despite the ranting from Oracle’s Bob Evans in 2012 that this was “vaporware”, it’s coming in SQL Server 2014. The latest demos don’t show 100x increase in query speed, but they 30x or so numbers I’ve seen are very impressive.

    Hekaton is an in-memory database technology, actually called In-Memory OLTP in Books Online. This isn’t a re-invention of the pintable concept from SQL Server 2000. Instead it’s a very well though out architecture and rather interesting in the way it’s implemented. The keynote video gives you a deep overview, though to use the tables, most of us don’t need to know the internals of how they work.

    However we do need to look at the restrictions, err requirements. Since these tables will exist in memory, obviously you need more memory, but more than you thought. The recommendation is twice the expected table size, to account for versioning. In addition, this memory is in addition to the buffer pool and other memory your instance already needs. That means much more complex memory calculations and monitoring for DBAs.

    The complexity of SQL Server continues to grow over time as more and more features are added to the product. Many of us don’t need much more than the core relational database functionality for many applications, but the in-memory OLTP tables might be one feature that can help dramatically increase the speed of your application.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 15.3MB) feed

    MP4 iPod Video ( 18.1MB) feed

    MP3 Audio ( 3.7MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Interfaces

    This editorial was originally published on April 23, 2009. It is being re-run as Steve is on vacation.

    Data quality is an issue in many of our systems that rely on humans for data entry. Even if you only import data from other sources, how reliable is the data that exists in those systems?

    I found an interesting article on computer interfaces and it highlights some of the ways that have been designed to work with computers and put data into, as well as get data out of, computer systems. Most of these are probably familiar to you and there’s nothing really groundbreaking in the article.

    It had me thinking, however, of whether or not there’s a better way to input and extract data from systems. I’ve been watching Star Trek: The Next Generation on DVD lately, and they primarily use voice recognition, but I see all kinds of flaws in that. My wife has worked with a lot of speech technology, and her current company makes the Dragon speech recognition software. I asked her if she thought it was good. She did, but it paled when compared to a good, old-fashioned keyboard. The rate of input and the few mistakes she makes typing far outweigh the benefits of using speech. Perhaps that will improve in the future, but I wonder if it will ever really supplant the keyboard.

    Multi-touch has gained a lot of notoriety lately, especially in presentations, but I’m not sure it’s a great way to get data out of a system for a single user. There are other possibilities, but in anything we develop, the rate of input as well as mistakes, are things on my mind. As a data guy, I am entirely too aware of how much work it is to clean data later.

    Managing, storing, and securing data all is great, and you can do the best job in the world, but if users can’t easily access and use the data, is it valuable? If it’s not correct, is it useful? The way we work with computers will likely evolve, and while I’m not sure what will work best, I do know that us DBAs will always be in demand to ensure the data is as correct as it can be.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Encrypting T-SQL Code

    This editorial was originally published on April 10, 2009. It is being re-run as Steve is on vacation.

    I recently engaged in a discussion with someone that was building an application on SQL Server. This person had a bunch of SQL code that was being put in stored procedures and then being sent to client sites. The developers were worried about clients modifying their code and wanted to send “secure updates” to the client by encrypting the stored procedures and giving the clients the encrypted text.

    Apart from the hassles of getting this to work, I asked by would they bother. There are decryption routines available and this isn’t meant to be a secure way to hide your code. Heck, even application code can be decompiled, and if they’re likely to mess with the code, they likely have the skills to get the source.

    So for this Friday’s poll, I’m wondering about how you feel about encrypting code in SQL Server. I want to know what you think.

    Is there a point?

    Is there a reason to encrypt stored procedure code? After all, there are many, many vendors that sell applications built on SQL Server, with stored procedures.  Most of that code isn’t encrypted and it’s usually not a problem. Most customers don’t mess with the code and there are usually prohibitions written into support agreements.

    Personally I don’t think there are many great ideas, and likely very, very few in the database space, that are worth securing. Someone doesn’t buy a software package so the can learn how you wrote it. Most of them buy software because it solves a problem and saves them time. If you can deliver a well performing, and good looking application, no one cares about the code.

    But I’m curious what the rest of you think, both end users and software developers. Is there really a good reason to worry about encrypting your code?

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • The T-SQL Paradigm

    This editorial was originally published on Mar 21, 2009. It is being re-run as Steve is on vacation.

    I ran across this post ranting about T-SQL. It’s got going pretty quickly with some less that professional responses. It’s cleaned itself up a bit, but it got me thinking for this Friday.

    My first programming was done in BASIC. From there I played with a little assembler before going on to Pascal and C in high school. The came LISP, APL, Fortran, more assembler, C++, and a little ADA in college. My professional career had me programming in Lotus 1-2-3, dBase, FoxPro, C, VB, and finally SQL with minor dabbling in HTML, XML, ASP, and some .NET.

    I think I’ve had a decent amount of programming experience in my life. In that time, I’ve found that most programming languages to work fine, and while I’ve enjoyed some more than others, I haven’t thought that any “sucked.” I wouldn’t want to write most modern apps in APL, but I don’t much think there’s any thing wrong with picking VB.NET v Java v C#. So for this Friday’s poll:

    Is T-SQL really a strange paradigm?

    Or SQL in general? Is it really messed up? Would the structures used by LINQ make more sense to anyone? Hardcore developers seem to like a different structure, but is it because it seems more natural to them? Or is SQL really such a strange beast.

    Many people seem to have trouble with SQL. Just read the forums here at SQLServerCentral to see all the issues that come when people try to query the database. But is it just hard to learn or is there a better way to build a query language?

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.