Voice of the DBA

Author: way0utwest

  • The Podcast is in the Windows Store

    If you’ve got a Windows Phone, or any of the Windows devices that support podcasts, the Voice of the DBA podcast is in the store. I did a quick search and found it, though the image isn’t there yet.

    podcast

    I was visiting a Red Gate customer last week and one of the developers asked why my podcast wasn’t in the Windows store. I hadn’t thought about it, so I did some searching today.

    It turns out the process is that you email a particular person at Microsoft. I did that, not expecting much to happen quickly, but I got a note back in a few hours the podcast was there. Amazing.

  • Better Searching on Google

    One of the keys to being a successful technologist is being able to search for information. Google has a lot of operators, and I ran across this list of terms, thanks to Kevin Kline.

    It’s on the GoogleGuide site and lists and defines the operators. I’d encourage you to play with them and practice using them. I use the “site:” operator often, and it’s helped me shortcut searches and reduce noise.

    I haven’t looked for the terms on other search engines, but I’m sure there are similar (if not the same) operators.

  • Always Abstract

    The way we build databases and design security is rarely done ideally. It doesn’t matter what your Utopian design is for schemas and objects; most of us make compromise as we deal with the pressures and diverse requirements thrust upon us in the real world. That’s unfortunate, but it’s also reality. I often see advice to use some best practice, like using only stored procedures and revoking all access to tables. I rarely see this in place, though I sometimes think that an investment in developer education would quickly erase any productivity losses from implementing stored procedures and probably reduce security issues.

    I don’t know we’ll get away from stored procedures, but I wonder if we can get away from tables. I’ve seen a lot of design refactoring lately that requires changing schemas. The use of views to hide base tables would allow developers to easily make changes changes. Implementing vertical or horizontal partitions (or federations), additing of new columns, and even enhancing your application with RBAC (row based access control) or encryption would be easy.

    This has me wondering if we should consider it a basic practice to not ever expose base tables and use views for all of our data access? Would it make sense to make a tCustomers table and a Customers view from the very beginning of development? We could grant rights to the view and use that for all queries. Perhaps SQL Server should include a dataViewReader role and dataViewWriter role that would allow quick assignment of rights to all views, and not all objects.

    I know there can be times when this wouldn’t work, and the proliferation of queries building on views built on views can be an issue. However, I also think it would make sense for data access through tables to be the exception, not the rule. Would this work in your environment? I bet it would for most of you.

    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 ( 17.0MB) feed

    MP4 iPod Video ( 20.6MB) feed

    MP3 Audio ( 4.1MB) feed

    Feeds are available at iTunes and Mevio

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

  • Guidance

    How do you manage SQL Server? Do you have a list of rules that tell you to do yy whenever xx happens? Or if yy doesn’t solve the problem, you next try zz? Some of you have guidelines like that, though it’s likely that the way you solve problems is somewhat internalized. You adjust your “rules” or “steps” based on the situation. Do you reduce or increase parallelism when you have high CPU? Either change might be the solution, depending on the causes of an issue.

    SQL Server is complex. We can’t easily reduce the solutions to problems to a set of rigid protocols that ensure optimal performance. If we could, there truly wouldn’t be as much of a need for DBAs as there is. Consultants and experts are well paid, and often very busy precisely because SQL Server is not so easy to tune and optimize in many organizations.

    That’s a bit of the point I saw in Grant Fritchey’s “Be Cautious Offering Guidance” piece recently. When trying to help someone improve performance, or reduce issues, or anything else, you can’t often give someone a rule of thumb that just works. You can’t give them a one sentence solution. Most things in life aren’t that simple, and neither is working on SQL Server.

    The environment in which your application runs is complex and there are lots of variables that can affect the advice or guidance that an expert might recommend. It’s the reason we see DBAs often saying “it depends.”

    Because it does.