Voice of the DBA

Category: Editorial

  • Source Code Security

    I’m not surprised, and I had expected to read about something like this much sooner. Apparently someone at the ride sharing company, Uber, posted a security key online in a GitHub distribution. I assume this was some sort of code repository for Uber that may or may not have been supposed to be shared publicly, but having used GitHub, I could see someone making a mistake and accidentally putting private code in the public space.

    Uber is worried as the key is a security authorization key used to access their databases. Someone apparently downloaded Uber database files and now Uber is attempting to track them down. The whole situation is a mess, but there are a number of problems here that we could learn from.

    I give a talk on encryption options in SQL Server and one of the main problems I see with symmetric keys in SQL Server is that they can be reproduced with the same parameters passed to CREATE SYMMETRIC KEY. This means that your source code is now a security hole, at least if the production values are stored in a VCS.

    However that’s a no-no. Developers shouldn’t have access to account information or keys that are used in production. There should be separate credentials used in development, precisely for this reason. If someone gets your code, or hacks a dev machine, they shouldn’t be able to jump to production.

    There’s also the issue of using a service like GitHub, or any online VCS. The distinction between private code and public code shouldn’t count on a human checking or un-checking the right box. I’d like to see some better separation, perhaps requiring separate accounts and connections for public and private distributions.

    As we see here, convenience can easily result in poor security. That’s not a trade-off we should be making with our security and applications. Especially not for software developers.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Software Engineering in Practice

    I ran across a review of a developer’s first year at a company. The company is endjin and the poster describes their first year as a “software engineer apprentice,” which is an interesting way to look at one’s early career. While it’s not for everyone, I suspect that many developers in this business could actually use a bit of apprentice time to solidify their foundation of knowledge.

    The post talks more about the way in which the work is done than the actual tools involved. A few are mentioned, but this is really a look back at the philosophical way in which the company solves problems. More importantly, it’s the view of an apprentice learning a trade.

    I wonder if this apprenticeship mentality might make a good approach for DBAs. It seems so many people working with databases lack fundamental SQL skills and even thoughtful approaches to solving problems. There are people that grow to be experts by diligently working through complex problems on their own, but it seems most people don’t get solid grounding in relational principles, or even learn good engineering practices, like measuring systems before and after changes are made.

    Many companies rush to get work done. They want code written quickly, which I completely understand. However if your staff isn’t well grounded in building solid code, then I’m not sure that poorly written applications are getting work done quickly. I suspect they’re just getting something done, which then has to be fixed, enhanced, and refactored before it allows work to move faster (if at all).

    All of that takes place in the time that it might take someone with more skill to do it well the first time.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Efficiency

    This editorial was originally published on Oct 22, 2010. It is being re-run as Steve is away on vacation.

    There was a debate recently about older IT workers and the fact that there is some age discrimination going on in this industry. While that’s probably true, it happens in other fields as well. Especially blue collar fields where the amount of work done often relates to some physical activity. Older workers might make less, or be paid less, because they do the job differently.

    Without getting into the debate about age discrimination, I wanted to get a feel for how you feel about your career progressing. I’m sure those of you in your 20s can’t conceive of being 60 and programming any differently than you do now, but times will change for you.

    One of my feelings is that there is a lot of value in experience. The latest .NET changes aren’t harder to use or understand than the previous ones, and the changes to T-SQL bring about new things to learn, but they aren’t really any more complex than previous features, commands, and constructs. For this Friday, I wanted to ask this:

    Are you becoming more efficient as you progress in you career?

    Maybe you can answer how you are getting more efficient. Are you developing skills that allow you to produce higher quality code in less time?

    I hope that most of you are, and the explosion of blogs, books, and events like SQLSaturday mean that you have more chances than ever to learn how to become more efficient in whatever type of technology you work with in your career.

     

  • Are There That Many GUIDs?

    This editorial was originally published on Oct 12, 2010. It is being re-run as Steve is away on vacation.

    Do a lot of people actually use GUIDs as Primary Keys? I haven’t used them much, and I would have thought that more people chose identity keys. It seems that most of the demos and examples I see from bloggers and speakers are constantly using identities.

    However an informal survey from Peter Bromberg showed that four times as many people actually had GUIDs as their primary keys. The blog actually says that GUIDs are not a good choice, but I’m not sure I agree with that. You can use sequential GUIDs, and you can avoid making them the clustered key, so I think they can work as well as anything.

    There’s nothing inherently wrong with GUIDs, and they should be unique across all of your rows. There have been some reported cases of duplicates, but for most practical purposes, especially in database work, you ought to be able to count on a GUID as unique. They even have the nice capability of being generated by clients, removing the need for an extra round trip when a client needs to insert multiple rows.

    I typically don’t use them because they’re long, hard to remember and type, and hard to view on the screen. I can’t easily compare rows in multiple tables, and it’s easier for me to work with integers.  I don’t recommend them, but if you are going to use them, be sure you understand the pros and cons, and use them appropriately.