Voice of the DBA

Author: way0utwest

  • Career Advice – Play Your Own Game

    I get asked this question fairly often. How do I find time to write so much, work on SQL Server, have a family, a ranch, etc. It seems that people often want to blog as much as me, or speak, or something else.

    It’s natural, I often look at others and think, why can’t I do what he does, or think that I should do what someone does.

    I don’t really want to be like someone, however. I don’t want to live another person’s life. I like my life. What I really would like to do is improve my life in some way.

    It’s easy to get caught up in trying to emulate someone that’s successful, but that’s the wrong thing. Really you want to take a piece of what someone else does and incorporate it into your life. We all look at the world differently and what might seem to work for someone else, or make them successful isn’t what wil work for you.

    Or work in your life.

    I try to stress with the Modern Resume that you want to find what works in your life, what you can handle, and what won’t become another stressor. Learn to do what works for you, in your life, and incorporate that.

    Don’t try to blog like me, or speak as often as I do, or write a book because someone you admire in this business has done it. Do it because it’s something that will work for you, and work at the appropriate time in your life.

    Play your own game.

  • Proving Your Identity

    I caught this article on Dark Reading that talks about the problems of multi-factor authentication. It’s interesting to me as I had written an editorial on passwords and mentioned that I used the fingerprint reader on my laptop. Someone pointed out that my fingerprints are likely all over the machine and could easily be lifted and used to gain access to the machine. That’s true, and it’s something I hadn’t thought of. To me a fingerprint reader is a convenience, but I might need to disable it for travel.

    As database professionals, we often rely on some other system to prove a person’s identity. For SQL Server, we typically rely on two common choices: a simple name and password, or some security token from the operating system. Those two have worked well, and since SQL Server 2005, we have also had additional encryption options that can be used to protect data, including the ability to use certificates to protect the keys that encrypt data. SQL Server 2008 also allowed Extensible Key Management, so that third party products could be used to secure data.

    As we store more and more data, and this data becomes valuable, it is more and more likely that individuals will try to steal data. While we can’t protect the data from insiders that need legitimate access, we do need to ensure that rights are properly granted and that our security systems have some way to verify the identity of the person or application that connects to SQL Server.

    It still feels like that the security mechanisms for SQL Server as a little immature, and the costs of implementing things like EKM are too high. I am hoping that it becomes more practical to implement better security over time, and we get more tools in SQL Server that help administrators manage permissions.

    Steve Jones

  • How I like to work

    This is a great sign. I see if every time I go to Brother’s BBQ in Denver and it never fails to make me smile.

    brothers

    I snapped a quick picture last week, and in case you can’t see it because of the sun, the sign says:

    OPEN EVERYDAY

    FROM AROUND 10AM

    TO AT LEAST 10PM

    Those are great hours, especially for restaurant. A little flexibility is good, especially if business is good. Why knock off if things are going well, but why commit to longer hours if there’s no business.

    It’s also fun, and fun should be a little more part of our lives.

  • More Triggers

    In the old days of T-SQL, back when we wrote “CREATE TRIGGER …. FOR INSERT” we could only have one insert/update/delete trigger for each table. Eventually SQL Server allowed us to have multiple triggers, and even have some control over in what order the triggers fired.

    Triggers are often hidden objects that confound DBAs who aren’t aware they exist. It’s not easy to tell when a table has a trigger on it, and since we don’t often use triggers, it’s not the first place people look when something strange happens.

    However triggers are useful, and it seems that there are many people using them. For this Friday, I wanted to ask how people implement triggers in their applications.

    Do you prefer one trigger for each table action or multiple triggers?

    I’m curious what’s the 80 in your 0/20 rule for triggers. Should all update actions be handled in one trigger? Or should there be one trigger for business logic  and a separate one for auditing? I’m not sure it matters a lot for performance, but I can see that it might be easier to manage and track fewer triggers. The flip side is that something like auditing can be handled with one trigger, and business logic with another: a clean separation.

    Triggers aren’t usually my first solution to a problem, but I do think there is value in using them. However I don’t see a lot of guidance about how to best implement them, so I’m hoping your answers today will help.

    Steve Jones