Voice of the DBA

Category: Editorial

  • Password Handling

    Best Buy Password form
    Bad form design or bad idea?

    I thought this article on Best Buy PC setup was amusing. Here’s a company that’s trying to provide a service. They’re offering to set up most of your new machine for you. To make sure that things work right away for you, they ask you to provide your password, so they can set a login password to your Windows/Mac. However the form has password below email, which might imply they will set up your email as well. That’s something I know many non-technical people might appreciate.

    Consumers probably think this is a good idea. Computer gets set up for them, and they pick a password. Technical people cringe. Password written down, given to stranger, stored by large company. What could go wrong? You can guess, or read the comments in the article.

    As DBAs, I am sure many of us have to deal with SQL authenticated user accounts. The recommendation is for Windows authentication, but there have been exceptions for various reasons at almost every company where I have worked. This Friday, I’m curious how you deal with a similar situation.

    How do you decide on a SQL login password for a user and get it to them?

    This is a process question, asking how you pick a password, and how you send it to the user. I assume most of you check the “user must change password” box, but if not, let us know.

    For systems where a password must be coded, I’d pick a long, hard to remember password, keep it in a safe location with other administrator passwords (something like Password Safe) and either type it in for an application or give it on paper to the developer/admin long enough to type it in before taking the paper back and destroying it. If it’s a user, I’ve often built separate passphrases for each user, customized to something I know about them, and forced them to change their password.

    Password security is hard, and complex, but so many administrators make it worse with constant, easy passwords they give to users. The password you choose sets an example, and “12345” or “asdf” are bad examples.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • What is Big Data?

    big data visualization
    Big Data visualization of “water” being spoken to a child.

    This industry is full of some very smart people. We tend to get some very strong opinions, and some rather snarky comments at times about the way the technologies that we use are presented. Karen Lopez (@datachick | blog) recently made headlines with her comments on big data. “What the heck kind of definition is that?” she asked when looking at the Wikipedia definition of Big Data. If “big data” is data that is “awkward to work with” then I know lots of people that have had to deal with big data anytime they had to work with outer joins.

    While I’m not sure big data is well defined, I do know that there are large data sets which can overwhelm relational databases, both in scale and the speed at which the data is collected. Microsoft added StreamInsight to SQL Server to help deal with the speed problem, but I’m not sure that relational databases can handle the size issues at the same time. Some large computing and analysis problems don’t lend themselves well to non-relational soluttions, and other technologies are needed.

    I do agree with Karen that big data, whatever that means to you, is not really in conflict with relational databases like SQL Server. There are lots of data sets that work well inside of a relational database, especially when you have built a solid data model and referential integrity. Many problems with relational databases come about because of poor code added to the platform, not a problem with relational platforms in general.

    Relational database systems are not “obsolete”, despite what some vendors of other databases think. I have complete confidence that SQL Server as a relational platform will be used for years to come.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Self Service SQL

    self service help and advice
    Self service isn’t always better.

    I was looking over the Microsoft Virtual Academy recently, and went through one of the courses they have on SQL Server for the private cloud. I was curious how this solution is being both implemented and presented. It was interesting, and I learned a few things, including the fact that Microsoft is looking to build self-service into this idea of a private cloud. Users can build a virtual machine from a template, with Windows, SQL Server, and more already setup. They receive a SQL Server they can use as long as they like, and can delete it when they are done with it.

    There are a few problems here, and they are similar problems that we’ve seen in the past as we pushed out more capabilities to individual users. The first one is that allowing people to create their own SQL Server instances can be problematic as they don’t do a good job of setting up maintenance. SQL Server is easy to set up, but a little more complicated to manage over time. I suppose templates could potentially have backups and maintenance built in, but if you do this with any scale, you might end up with storage and space issues as well.  There’s only so much automation can do with limited resources, and I could see this ending up causing more infrastructure problems over time for IT staffs.

    The second issue is that people just don’t manage data well. How many people would delete a virtual machine without a final backup? How many people would create machines, load data, and then forget they had data out there? Apart from security concerns, there are likely to be efficiency concerns. How many people might create their own database server for financial data, even though the person in the next office might have already done the same thing? How many reconciliation problems will be brought to the DBA when people load different data sets into their servers, run reports, and then try to compare the results?

    I think IT self-service is a good idea in many ways, but it’s not the answer for all problems, and without some controls, I can see it easily causing as many issues as it solves.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Is Software Engineering Dead?

    Software Engineering
    Are textbooks like this obsolete?

    Is Software Engineering dead? It’s a premise that’s in this article from Bloomberg. It calls the job a career dead end where job prospects decline after one reaches 35 years of age. I think that’s a naive view of the industry, despite the quotes from Craig Barrett and Mark Zuckerberg. While the best of the best might peak in their careers at the same age as many athletes, that doesn’t imply that the career choice is a poor one.

    There’s a discussion on Slashdot as well, and I was struck by a few of the comments, which seem to suggest that if you are still just a “software engineer” at age 40, you aren’t very good at your job. It seems that some people seem to think that everyone in this business is constantly looking to move to a new job and advance into management or they aren’t successful . I saw analogies with other industries thinking that same thing, that experienced people would not still be doing the same job after 20 years.

    That seems crazy to me. So many people in various industries continue to improve at their jobs, and do the same work for decades. Carpenters, doctors, accountants, all continue to improve their skills over time, and while some may more into management or open their own firms, many will continue to do their same jobs until they retire. And they’ll enjoy their careers.

    I don’t deny that ageism exists, and that older programmers often can’t, or won’t, work as many hours as younger ones, but that doesn’t mean they aren’t worth their salaries. Good, experienced programmers produce better code, with fewer bugs. Once managers learn that working more hours doesn’t equal better code, or even more code, the entire industry will start producing better applications.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.