There’s still time to register if you’re in the Denver area, and you will get a full day of free training on SQL Server, .NET Mobile, Office, Kinect, Windows, and more. There are quite a few other professional development talks you can attend as well.
Pass the word and visit the site for more information or to register.
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.
I saw this link about a company that moved (Goodbye, CouchDB) from a NoSQL database (CouchDB) to a relational one (MySQL) because of some problems they experienced. Sauce Labs provides testing services in the cloud for developers using the Selenium framework.
The first link is a blog post that talks about some of the things they initially liked about CouchDB and then the problems they experienced. Their move to MySQL showed better performance and stability over the CouchDB they were using. It’s an interesting read, not too long, and it seems well thought out.
I think that this isn’t a knock on NoSQL databases, and I do think there are problem sets they are well suited to solve. I don’t know that I think because your developers don’t like SQL is a good reason, but there are problems with scale and size that are better handled with some NoSQL solutions. I’m an RDBMS person, but I don’t expect everyone to be that way.
However this does say a few things about NoSQL maturity. Many of these products have gotten popular quickly, with some success stories, but that doesn’t meant they are necessarily ready for your application unless you have staff that have lots of experience with the tools. These are young platforms, they have problems inside the code, especially if you deviate from the way the authors used the platform, and you may have issues.
Experience matters. Just as many people have issues with SQL Server scaling when they don’t know how to build a good data model or write efficient queries, I suspect that picking a NoSQL database because it’s cool, or seems easy to implement, or it worked well at some other company. I would almost always suggest that you stick with platforms that your staff is very experienced with, since they are likely going to have issues at scale on every platform, and their experience can make a difference.
Note that this assumes you have good people. Just because you have a DBA with 10 years of experience doesn’t mean he or she is necessarily good. They could easily have 1 year of experience 10 times. You want people that have worked on a variety of systems in different areas.
As long as we have people with this attitude, we are going places:
“If you hustle – all out, fully hustle – and you succeed, then you gain the satisfaction of a job well done. If you hustle and fail, you never have to worry about what might have been if you’d given everything.
If you slack off, you might get lucky and still succeed, but there’s little satisfaction other than the temporary thrill of escaping with your life. If you slack off and fail, you have to live forever with not knowing what you were truly capable of.”
Voice of the DBA 