Voice of the DBA

Category: Editorial

  • Making Choices

    I wrote about shutting down some travel for the foreseeable future. Its been a long couple of years for me. If you look at my speaking schedule, I’ve presented at an average of 20+ events for the last few years. This year was a few less, but I’ve had more travel outside of that. By the end of the year, I’ll have spent 9 weeks outside of the US. While some of that is vacation, it’s a lot of time away from home. In addition to the events, I’ve had other travel for work that doesn’t appear there, as well as some vacation time for volleyball (my daughter competes) and family time.

    Lately I’ve been seeing all the tweets and posts about SQL Bits 2018. I won’t be going, which is sad for me. I love the event, it’s my favorite and my wife would love to go with me sometime, maybe in 2018. As I see speakers submitting and the excitement building, it feels like I should just send in a session, but I realize I need to stick with my decision.

    Making choices is hard. For a couple years I’ve been saying  I need to travel a bit less, but I haven’t done a good job of slowing down my travel. I find that I’ve done that with other work demands in the past (and personal ones), and I see plenty of other people doing the same thing. This fall I made the commitment that I’d limit travel next year, and I talked to my manager as well. We agreed on a plan, and she’s holding me to the plan, even when I get a bit excited about new events.

    My current job allows me some flexibility in how I work, but in past jobs I’ve had similar ways that I could change my job, if I made the effort do so. Your employer will ask a lot of you, and often keep asking. I’ve certainly had some bosses that were unreasonable and demanded too much, but most were willing to work with me. It took me a number of years to learn to push back and say no, as well as learn to make choices among different situations. I find if I don’t make choices, I’ll tend to over commit and under deliver, while being disappointed in myself that I couldn’t make it all work. Or I become a little burned out, spending too much time trying to keep all the balls in the air and running myself ragged.

    Balance is important, not only between work and life, but also within work. I find that the more I make choices and stick with them, the better adjusted I am in all of my life. I’m a little sad that I won’t speak at as many events next year, but I’ll pick and choose a few, and hopefully get some things done at work that I’ve been putting off. I’m also hoping that life will seem less chaotic and busy in general, with a little more time to relax and smell the sawdust.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.3MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • It’s Time for SQL in the City

    Today is SQL in the City 2017. Once again we’re streaming the event online, live from Cambridge in the UK. I’ve flown over, along with Grant Fritchey and Kathi Kellenberger to entertain you for the day. We’ll be broadcasting at 11am in the UK for five hours before we take a short break and return for a 1pm EST start of the second broadcast. You can still register and we hope you’ll tune in for a few a session or two, or all of them if you can convince the boss to give you a training day. You won’t know unless you ask.

    I’m excited to show off a few things today, as I’m sure Kathi and Grant are as well. Our developers have been hard at work throughout the year, improving our software and adding new features, while fixing a few bugs. It feels like the pace of change is steadying out, with most products releasing changes every two weeks, but we’re adding a lot more exciting and interesting changes. It seems that the products are maturing well, in ways that I didn’t expect.

    I’ve been especially excited by the changes in SQL Clone this year. We’ve really  grown this product up, with the team being reponsive to customer requests. It’s exciting to be the one to present some of the changes to you, as well as try to introduce others to the product. This is one of those products that I wish would have been available 15 years ago as I would have saved lots of storage costs as well as gained a tremendous amount of flexibility.

    SQL Prompt and SQL Monitor have also had great years, and I’ve been impressed with their growth. Unfortunately I didn’t get the short straw and had to leave those products to my colleagues. I guess I can’t have all the fun. Maybe I’ll try to photobomb my way into one of those sessions.

    Presenting at events is exciting, and I’m looking forward to the day. It’s long, but it will still be a fun time. These streaming events are also a neat experience, as we’ve got a bit of a TV studio feel, with multiple cameras, displays, tape on the floor, and more. For someone that is used to sitting at a  desk and working at my pace, I get a little excited by the efforts put into the broadcast from our IT staff. We have various schedules and checklists, and I’ve spent the last couple days rehearsing the talks.

    I still like live events, and hope we’ll do a few in the future, but for now, sit back, relax, and enjoy SQL in the City from the comfort of your office.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Sharing Data

    One of the things that’s written into various computer laws is that unauthorized access of a computer system with another’s credentials is a crime. That’s been drilled into me at various organizations where no one was supposed to share any credentials. That is something many sysadmins drill into users, while sharing their own system level credentials for accounts like root, sa, system, and more. I’ve seen no shortage of these accounts in use across multiple services or multiple people from those that would admonish a manager for sharing their password with an assistant.
    This week Troy Hunt wrote about politicians sharing passwords, and the problems with doing so. It’s an interesting read, and certainly points out that the expediency of having users share a workload has plenty of downsides in accountability and auditing of actions. I think there’s little excuse for sharing security credentials in UK gvoernment as there are other solutions to handle this issue. I am more sympathetic in real time environments, like hospitals, where the login process might literally cause a death in the event of a delay.
    Leaving aside the authentication aspect, we often share data among individuals inside of an organization. In fact, outside of sysadmins, there might not be many people that really understand who should have access, let alone who has access, to some data. In fact, over time it seems that most organizations tend to lean towards allowing an ever-growing number of people to access data in file shares. While we might prevent database access and grant/revoke this at times, the output from our systems often ends up in Excel sheets or other files and people that might not have direct access still see the data.
    The real physical world is just as bad, since many people may leave data lying around on desks or tacked to a wall. Just like credentials on a post-it, we have lots of data available for others to read, though physical access is required. However, have you thought about how many people have physical access? It’s not just your co-workers, but also janitorial staff, tradespeople, and others likely wander regularly through your office spaces.
    Security is a tough battle, one that is interesting in that most of the time we don’t need much more than good passwords. Most people don’t have the time or inclination to deal with their own data, much less yours. However, when an attack is targeted on your organization, from outside or within, it’s extremely difficult to ensure data won’t get lost.
    I don’t have a great solution, but I do think that there are good reasons to limit access to data on our systems, not the least of which is auditing and accountability. Beyond that, however, we have to hope that our users have some judgment about with whom they may share reports and other data.
    Steve Jones

  • Singular or Plural

    There are all sorts of interesting debates that developers will have about programming. One of those I’ve written about in the past is Spaces v Tabs. There’s a lot of discussion about that one, and certainly no share of strong opinions. I’m sure there are plenty of other development paradigms and habits that will create debate, arguments, and perhaps strain some working relationships.

    While I’m not looking to upset anyone, I ran across a discussion recently and thought this would make an interesting debate. If you’ve got an opinion, please share how and why you might choose to follow your convention. Examples are helpful and may enhance the reasons why you go choose to build systems one way or the other.

    If you examine any sample databases out there, you will run across tables named like this: Customers, Orders, Cities, etc. You might also find Product, Person, Address as well. If you are paying attention, you might notice that my examples are both singular and plural in their form. There are no shortage of debates on the topic, but I’m wondering what many of you think.

    I’ve tended to build tables with plural nouns in the past, but I think that’s because the first few people that taught me did that. As I’ve read more and listened to others explain their design decisions, I’ve embraced singular names. After all, the entity being modeled is often a single instance of a type. A Person or a CreditCard, not a series of them, though we could certainly argue the table is a set of people, so use that.

    Ultimately I’m not sure that it matters much in any particular application. We certainly have databases that using each convention, and probably a few that use both inside the same schema. I think choosing an entity name that is easy to understand is important, and maybe the idea of singular or plural names matters less. After all, as long as you’re not naming tables F42 and H1492, everyone will get used to the convention.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio (3.5 MB) podcast or subscribe to the feed at iTunes and Libsyn.