I keep a list of blog post ideas in RememberTheMilk.comin case I run out of ideas. After piling up dozens of them, I’m giving up and setting some of my favorites free. If I couldn’t write these in 2011, I’ll probably never get around to it. If you’re looking for inspiration, here you go:
Why Bad People Hate Good DBAs – Developers hate us because we find flaws. Sysadmins hate us because we identify hardware problems. Network admins hate us because they can’t blame the database. Just because people hate you doesn’t mean you’re doing a good job, though.
5 Database Queries You Should Never Make – I just love this post title, but I couldn’t decide if I should go controversial (CLR, cursors, auto-close, etc). There are good uses for some nasty tools.
Role Playing for Outage Preparations – If you’re thinking about moving your databases to a hosting provider or the cloud, play pretend. If your database was inaccessible now, how would you troubleshoot it? Start by verifying network connectivity out of your office, then to your cloud provider, then to your specific database. If any of those is down, who do you call? Make sure your support team understands these borders – the DBA shouldn’t get a call if you can’t ping Yahoo.com.
If DBAs Wrote Spam – Can your database last all night? Are your users complaining about your lack of staying power? Ask your doctor about VARCHAR(MAX).
Appreciation for Deprecation – When a SQL Server feature is deprecated, how should you react? What does it mean? How should you monitor for your own team’s usage of deprecated features? Have you explained to your team what features should no longer be implemented in new code?
SSMS vs BIDS vs Visual Studio – SQL Server users have three tools to choose from when they interact with SQL Server. Which tool is right for who? When should you learn to use a new tool? What advantages do third party tools like Quest Toad and Aqua Data Studio offer?
Great Quotes for Technology People – Starting with this one from director David Fincher: “Everything seems really simple on paper until you take a camera out of the box.”
Cobol, Compass Adjusters, and the Cloud – Yes, you have to make sure your chosen field doesn’t become obsolete, but even when careers go away, they don’t really go away. It can even be an opportunity to make more money if you’re one of the few who are still really good at it.
sp_Captcha – One of my clients asked me to write a captcha in T-SQL. No, wait, hang on – it’s cooler than it sounds. They needed to make sure that only human beings ran a particular stored procedure, and that it was never automated by accident. I ended up writing a challenge/response system using a parameter. If the param was null, the stored proc would print a question that would be difficult for a computer to answer. The next time the stored proc was called, the answer would be passed in via the parameter. If the answer was right, the stored proc ran – if not, it emailed the DBA team and paused via waitfor. I can’t share that code, so I wanted to rewrite something similar.
Really Good Experts Know People, Not Answers – Expertise isn’t just about knowing a lot of stuff. It’s about knowing a lot of people who also know a lot of stuff. I don’t know much about CLR, for example, but the fact that I can point someone to Adam Machanic helps me more than using Google.
Guess The Date – I was going to have a showcase of everything that happened on the day SQL Server 2000 came out (but not include 2000’s release), and have people guess the date. Hopefully folks would also figure out that it was the 2000 release date too.
Plot a Path to a Precon – If your New Year’s resolution last year was to speak more, and you accomplished that, maybe it’s time to set a bigger goal. You too can speak at a conference pre-con session and get paid to share your knowledge for a day – but you gotta map the route to get there. Start by building an outline, and then build a series of 1-hour sessions that you can combine into a pre-con. Make sure each hour works, and then the combined session will be even more likely to succeed.
If Movie Reviewers Wrote Consultant Reports – “Two thumb drives up. The application starts out well, and then has a knockout twist halfway through. The staff left the project, and it becomes a horror film. The IT director manages to pull it off, though.”
The Shadetree DBA – In the 1960s when cars were simpler machines, we pulled our cars under a tree for some comfortable shade and set about working on ’em ourselves. The 1970s brought complex emissions equipment, and the 1980s brought unreliable car computers. These days, some cars can go tens of thousands of miles with nothing more than oil changes. Right now, databases are at the 1970s phase, but the cloud has the potential to make larger and larger databases run themselves without human interference help.
Ahhh. I feel better already getting these out of my to-do list. Sometimes you just gotta know when to let go.
13 Comments. Leave new
This list is very good for 2012. Awaiting to see in your blog.
Ayyappan – sorry, I wasn’t clear. I’m not writing these in 2012 – I was giving the ideas out to readers if they’d like to blog about it.
I didn’t know you had this site as well. I like the url!
Thanks, man! I wanted something reeeeally short. 😀
A slightly different tack on the shadetree dba wouldn’t involve the cloud but instead all those databases that are running just fine all by themselves, in some cases without anyone watching them. The analogy might extend to the fact that on newer cars you can’t just pop the hood and stick a pencil in the carburator, you have to take it to the dealer and let them hook it up to their OBD II diagnostic machine. Or maybe that’s a segway into that remote monitoring and diagnostic project MSFT announced a while back, which as I recall you weren’t too enthusiastic about. Or remote dba services in general. Just some random thoughts.
Chuck – see, there you go! Start writing. 😀
I have a few questions regarding sp_captcha.
The logic is:
No Param,Generate question
Param, Validate Answer
If the question and answer are not stored anywhere how can we validate that the answer provided was for the same question?
If we only have a list of questions and no answers stored, how do we know which question was answered?
Also, if the stored procedure is run by many users how do we know which questions were asked to which user?
If we do something like, “What word does this remind you of: T3l!vIs0n”, can we be sufficiently random without repeating the same question too soon or generate such intelligent question in a very small time?
Assuming, we can do both; this method maybe suseptable to attacks.
Hemanth – In my implementation, I stored both questions and answers in a secure location. I didn’t have to worry about running from multiple users, but it’d be pretty easy to pass back two things instead of one – an authentication token and the question. The user would have to pass back in the token and the answer. The token wouldn’t have to match the question – it could be a separate table of history. Good luck!
Too bad, i can’t write on any of these. I ain’t no Dba, but RTM.com is something i can use. Thank you!
[…] day, and this time it is Brent Ozar’s (Blog|Twitter) turn to inspire me. In his blog post ‘Blog Posts I couldn’t develop in 2011’, he mentioned a curious little stored procedure called sp_Captcha which he developed for a […]
[…] more ideas, check out the Blog Posts I Couldn’t Develop in 2011. Posted on December 11, 2012 by Brent Posted in Blog […]
Thank you for every other fantastic article. Where else could anyone get that kind of
info in such a perfect manner of writing? I’ve a presentation next
week, and I’m at the look for such information.
If you’re willing to spend a little bit of quality time shopping
through various policies and speaking with car insurance agents, finding affordable
student car insurance is a breeze. You will probably notice that after looking through all
of the car insurance web-pages, there were a couple companies that were giving out better deals than
others. ” After a few weeks, Kelly received an email from her agent stating she owed the company more because her car had been in an accident over six years ago.