- Jan – T-SQL Tuesday #26 : Second Chances (summary)
- Feb – T-SQL Tuesday #27 – Big Data (Round up)
- Mar – T-SQL Tuesday #28 – Jack of All Trades, Master of None?
- Apr – T-SQL Tuesday #29 – The Most Useful Feature of SQL Server 2012
- May – T-SQL Tuesday #30 – A DBA’s Ethics
- Jun – T-SQL Tuesday #31 – Logging
- Jul – T-SQL Tuesday #32 – A Day in the Life (roundup)
- Aug – T-SQL Tuesday #33 – Trick Shot (roundup)
- Sep – T-SQL Tuesday #34 – Help! I Need Somebody –
- Oct – T-SQL Tuesday #35 – Soylent Green – (Roundup)
- Nov – T-SQL Tuesday #36 – What Does Community Mean to You? (roundup)
- Dec – T-SQL Tuesday #37 – A Month of Joins (roundup)
Over the past couple of days I’ve been attending a training course in Paris, and one evening, to relax I watched ‘Soylent Green‘, a classic science fiction film. If you’ve not seen it, I recommend it, and go and watch it …
So, what I’d like to know is, what is your most horrifying discovery from your work with SQL Server?
We all like to read stories of other people’s misfortunes and, in some ways they help to make us better people by learning from them. Hopefully, there is nothing as bad as Charlton Heston’s discovery, but there may be in its own way.
A couple of extra thoughts for motivational thinking…
Soylent Brown – You did a post, Great Job!!
Soylent Orange – You did a post, it made me wince!
Soylent Green – You did a post, it made me wince, and it included some T-SQL.
For a while, I was in an amateur pool league. No, not the one involving water and swimming, but where you try to sink balls into pockets. It was a lot of fun and is a challenge both for your motor skills as well as your strategy. I still shoot from time to time, as well as hang out with my old pool buddies.
One thing guys would get into is trick shots. Two and three rail bank shots, masse shots, or jumping the cue ball to hit the target. Most of these shots weren’t tournament legal, but they were fun to try and nice to impress the ladies. More than that, they were a tool to teach you the physics of your pool game. You could see how throw and English could affect your shot, or how balls would behave after impact.
Just like so many other things I do in my life, the trick shot lessons translate over to SQL Server. How many times have we built something neat or puzzled out a particular bit of logic that, while it may not have been particularly useful, taught us about how SQL Server behaves. This month’s T-SQL Tuesday is all about this and the assignment is two-fold:
- Show us a cool trick or process you developed, maybe a DMV you used or some reporting logic you created. It doesn’t have to be useful, just something that you thought was pretty neat.
- Tell us what you learned from this trick. Is it something about an oddity in SSRS? Maybe with the query processor? Whatever you did, tell us how it gave you insight in to how SQL Server works.
- T-SQL Tuesday #015 – Automation (summary)
- T-SQL Tuesday #016 – Aggregation (summary)
- T-SQL Tuesday #017 – APPLY Knowledge (roundup)
- T-SQL Tuesday #018 – CTEs (wrapup)
- T-SQL Tuesday #019 – Disasters and Recovery (wrapup)
- T-SQL Tuesday #020 – T-SQL Best Practices (wrap-up)
- T-SQL Tuesday #021 – A Day Late and Totally Full of It
- T-SQL Tuesday #022 – Data Presentation (round-up)
- T-SQL Tuesday #023 – Joins (summary)
- T-SQL Tuesday #024- Prox N Funx (Summary)
- T-SQL Tuesday #025 – Invitation to share your tricks (summary)
OK, it’s time for TSQLTuesday again and Jen’s making me write something since we’re hosting this month. So the topic is resolutions, and that in itself isn’t a topic that’s near and dear to me because frankly I just don’t believe in them. I don’t think you have to wait until a new year begins to resolve to do something you’ve been meaning to do. In fact, that pretty much dooms you to not completing it because it takes more than the turning of a calendar page and a romantic notion to accomplish something. If it were really that easy, you would have done it already so it wouldn’t be a big deal.
Your new year can start anytime really. Hell, doing a new year’s resolution doesn’t even line up with my review period at work, so if I relied on the new year to start something new I’d lose 3mos making good on what I’m supposed to accomplish for work. People in IT quite often put personal goals in their yearly goals at work. Things like getting certified, or perfecting a process, or taking management classes, etc are all things that are commonly found in your yearly goals at work. So if you’re going to make some kind of resolution to do something, or to stop doing something, why not put it where it actually makes more sense… in your work goals. Your bonus quite often relies on you completing your goals so it’s really the perfect place. And it gives you a better excuse to have the resolution to begin with because you can use the bonus as motivation.
So even if you’re going to make a resolution at work, try to make it something you can actually do. One of the biggest reasons for failure is someone will set a goal that’s completely ridiculous for them and when the goal starts slipping they get discouraged and just give up. I’d like to get my MCM this year, but I don’t even have any of the lower certs yet. Well, chances are you’re not going to make it dude.
- T-SQL Tuesday #002: A Puzzling Situation
- T-SQL Tuesday #003: Relationships
- T-SQL Tuesday #004: IO
- T-SQL Tuesday #005- Reporting
- T-SQL Tuesday #006: “What About BLOB?”
- T-SQL Tuesday #007: Summertime in the SQL
- T-SQL Tuesday #008: Gettin’ Schooled
- T-SQL Tuesday #009: Beach Time
- T-SQL Tuesday #010 – Indexes
- T-SQL Tuesday #011: Misconceptions
- T-SQL Tuesday #012 – Why are DBA skills necessary?
- T-SQL Tuesday #013 – What the Business Says is Not What the Business Wants (Summary)
- T-SQL Tuesday #014 – Resolutions (summary)
I was giving a presentation recently and someone in the audience started to ask about why I recommended against a certain technique. Without getting into it, this person kept saying that she had to implement things her way since the “business” said they needed it done that way. However a little digging showed that the business didn’t really understand the technology. They were asking for a result, and she took them literally in how she implemented a process. A classic impedance mismatch.
I think we’ve all had situations that are similar. The business, the client, the customer, is asking for something, but they don’t know how to ask those of us building the technology. Or they don’t understand the implications of asking for something like “absolutely zero data loss” to be implemented.
The official topic this month is:
What issues have you had in interacting with the business to get your job done.
This month I’d like to step back from the deep technical stuff and ask “why are DBA skills necessary?”
I don’t want to color people’s opinions by giving my own yet, but some things to consider are:
- What problems have you seen in your career that could have been avoided with some DBA skills?
- At what point does a SQL Server installation need a real DBA to look after it?
- How could DBA input help prevent design problems in data applications?
- Should there be cross-over been developer skills and DBA skills? What about architects? Storage admins?
- How can business continuity be affected by lack of DBA skills?
- How much can we rely on auto-tuning to ensure performant work loads?
- Is Microsoft doing enough to foster DBA skills as a point of excellence?
- What about on other RDBMS platforms? What about no-SQL?
I could go on for hours… I’m really looking forward to seeing where you take this topic and I’m expecting some great posts.
Why are so many Misconceptions in SQL Server?
SQL Server as a product is maturing with every new version since its inception and getting better and better over the years. But there seems to be lot of misunderstanding of some SQL Server concepts in the community and probably in my opinion its because of one or more items listed below.
1. While some information holds true in previous versions but they don’t hold true in newer versions (after some components were re-written, optimized).
2. Bugs in older versions are fixed in newer versions.
3. Taking the words out of context from someone’s publication/blogs etc…
4. Someone simply misunderstood the concepts.
5. Never realized the depth of the internals or the scope of the subject.
6. Taking marketing fluff as truth.
7. Too much generalization of the facts based on one or two incidents.
The possibilities for writing up a post on this topic invloving SQL Server are enormous even if you are a novice blogger or the industry expert on SQL Server. So get ready with your [misconceptions, myth-busters, de-mystifiers, do you know, back to basics, fact checking] posts on SQL Server and help the community learn more stuff while setting the facts straight.
I want to take a moment and request if you are working on a misconception that was already busted by someone else in the community and your approach is also very similar then please give credit to the person that did the work prior to you in your post.
Indexes are strange things. You never need to explicitly create one to create a fully-functional database, but if you want a database to perform well, they’re indispensable.
And there are so many aspects to write about! Like internals, covering, clustered, xml, fulltext, b-trees, hints, maintenance of, included columns, filtered, redundant, missing and tons more.
In fact my SQL Server 2008 Administrator’s Pocket Consultant (The first handy textbook I could grab) has an index entry on “indexes” that has 22 sub-entries.