Voice of the DBA

Category: Editorial

  • Looking at SOX

    What do you think of SOX?

    We republished an editorial recently that I wrote early on when the Sarbanes Oxley Act (SOX) was starting to become a part of daily life for IT people. SOX was really written to the rest of the business, requiring accountability from the executives in a corporation. However it seemed to quickly become a burden for many IT departments, with the interpretations of the act requiring additional documentation for all actions. There were often security changes required that interfered with the way in which many technology groups operated.

    The act was passed in 2002, nearly a decade ago. Now that it’s been a part of public corporate life, I wanted to ask the data professionals out there what they think of the act and its impact on their jobs. For this Friday’s poll:

    Does SOX impact your work?

    Is there an increased level of effort and work for you or is it just a part of your job now that you accept and are used to? I would think that after years of being subject to the regulation that most people would be used to it by now.

    I know when the act was first passed there was concern that our IT department would be understaffed for the documentation that was required. However we were an ISO 9001 certified organization, and we quickly realized that much of our work to maintain our ISO status could be re-used for SOX compliance as well.

    The biggest hurdle we faced was in implementing better separation for development and production groups to ensure that systems were accessed by the appropriate individuals. It seemed to me that this was a change for the better at my company, providing better security for us.

    Let us know this Friday how SOX, or even PCI/HIPAA impact your workload.

    Steve Jones

    The Voice of the DBA Podcasts

  • Implicit and Explicit Conversions

    Don't trust implicit conversions

    In a talk recently with some people I had someone note that the always chose to use explicit conversions on data types to prevent any unforeseen issues. That’s what I’d recommend as well. I have seen code in production function for years using implicit conversions, only to start failing when someone finally entered an invalid character in a row.

    How does that happen? Usually when someone is using character data types to store data that can be represented as character data,  even though the data must be dealt with in it’s native format. An example of this is storing a date as a varchar(10) or sticking numerical quantities in a character field to preserve formatting notations like dollar signs, or commas.

    That kind of code can work , pass a QA process, and live for years in a production system. However sooner or later someone will enter data that will break a query and return an error. Depending on your error handling system, this can be problematic to track down because it’s very data dependent. The code might work for some data sets but not for others.

    The best advice I can give is to store data in the proper data types whenever possible, and use explicit conversions when comparing data that might be of disparate types. Don’t always expect ’09/01/2001′ to compare to getdate(), and don’t expect ‘1’ to equal 1 in your code. At some point bad data will get into the system and those comparisons will error out.

    Steve Jones

    The Voice of the DBA Podcasts

  • A SQL Conference in the Sun

    SQL Server Connections is in Orlando this Spring

    The SQL Server Connections spring conference is coming up in a few weeks in Orlando, FL. This is a part of the DevConnections multi-technology conference and this event is the chance to get some great SQL knowledge and inspiration from experts in a fantastic location. Once again SQLServerCentral is sponsoring a track at the conference; Brad McGehee and myself will be down there, looking forward to meeting a few of you.

    I think that conferences are a great way to take a break from work, recharge, and get some excitement back in your job. The speakers at these events teach me about SQL Server, and inspire me to come back and try some new feature or technique in my own environment. I might get the solution to a problem, and usually find that the work is just a little more fun when I return. To me, that’s an ROI that’s hard to argue against .

    DevConnections puts on a great conference event, recognizing that while people want to come learn, they also want to do it in a nice location. This event is in Orlando, with great weather, at a place you can bring your family for a mini-vacation before or after the event. There’s no shortage of things to do in Florida, and it’s a relatively inexpensive place to visit. The conference hotel even offers complimentary transportation to many popular attractions. Who knows, we might even end up sitting by the pool and talking high availability or Resource Governor in the late afternoons. That’s more interesting to me than discussing things in a conference hallway.

    So many people are hybrid IT workers, using more than one technology, and this conference reflects that. The last time I went to a DevConnections event,  I attended mostly SQL Server sessions, but did manage to see an ASP.NET session and a couple Sharepoint presentations. Becoming more rounded in my IT knowledge has paid off for me in the past, and the DevConnection events give you the chance to grow skills in a variety of areas.

    Hopefully I’ll meet a few of you at SQL Server Connections this spring and share a few drinks while we talk about SQL Server.  I should be easy to find in the Hawaiian shirt and cowboy hat.

    Steve Jones

    Save $200 with the “DevCon1” code when you register.

    The Voice of the DBA Podcasts

  • NoSQL is Not the Answer

    The NoSQL Logo

    There’s a lot of talk and press around NoSQL databases, which are a class of systems that are different from relational databases (RDBMS). Most of us are familiar with the competitive RDBMS’s to SQL Server; systems like Oracle, DB/2, MySQL, PostgreSQL, and a few more. NoSQL systems are less well known, going by names like Cassandra, MongoDB, and the best known system used by Google, BigTable.

    It seems there are a lot of ranting and raving about which system is better, and even some comparisons that look at performance in different ways that we use systems. I found a SQL Server v MongoDB comparison recently. It seems to show that SQL Server lags way behind MongoDB in terms of simple insert, update, and select operations. I’m not sure it’s the best real world test, but it shows some interesting results.

    Those comparisons  are important, but ultimately we do a lot more than simply insert rows and select from basic small sets of data in many of our applications. I see many systems making use of complex queries with aggregations, multi-table joins, and complex sorting operations. These might work well in a NoSQL system, but they also might not. Who knows how well complex business transactions and reports will perform on these platforms. Someone will have to try and see if these systems can handle those needs.

    NoSQL is worth examining further and learning about. I would not be surprised to see some of the features, such as easier scale-out, coming to SQL Server in the next few years. However I’m certainly not ready to view NoSQL systems as any type of evolution of the RDBMS. I think it’s much more likely that NoSQL systems solve a certain domain of problems better than a row-oriented RDBMS, much like column-oriented databases seem to be much more efficient at working with some types of data warehouses.

    Steve Jones

    BTW, if you want to listen to a little NoSQL humor, check out this video. It’s Not Safe For Work (NSFW), so be sure that you have a properly configured “cone of silence” so as not to offend others.

    The Voice of the DBA Podcasts