- 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)
As many of you know already, I decided to declare December 2012 as the month of the JOIN by writing the A Join A Day blog series. So, it should be quite obvious what this month T-SQL Tuesday is about. You guessed correctly — I would like you to join me in talking about joins. Now you might think “If Sebastian is writing 31 posts about JOINs already there is nothing left to write about.” But I can assure you that there is still plenty out there. In my series I am going to cover just the basics. For example, what is a cross join or an anti-semi-join? What is the difference between a hash and a merge join? There are many things I won’t be able to cover, for example how to write efficient join queries.
Your mission – should you accept – is to write about topics like the good and the bad patterns of joining you have seen out there or really anything else that comes to your mind when thinking about joins:
- Have you had to deal with a slow monster join that you were able to conquer? Let us know how you did it.
- Have you noticed a join pattern in use that is really not good for readability but you come across it time and time again? Tell us how to do it better.
- Have you discovered a really cool way of using the APPLY command instead of a JOIN to force the execution engine to utilize the existing CPU resources more effectively? We would like to hear about it.
And if you have a topic that you always wanted to write about but that is only remotely related to joins, feel free to use it anyway and make sure to tell us why you think it is related to joins.
Hope to see you (or at least your post) next week at the party.
Merriam-Webster defines Community as “a unified body of individuals”. For me the SQL Community is something that has helped me in my career; whether it is questions that I’ve had along the way where I was stuck, helping other DBA’s with issues they were having, networking with other DBA’s or making contacts for the future. The SQL Community is just that; we are a team. All on the same team; if one falls we pick each other up. I’ve never been part of a group of people who want to help each other more so than the SQL Community.
One of the best conferences I’ve been to is the PASS Summit. I was fortunate enough to attend last year and this years will provide new attendees the same fortune and opportunities that I have had. Sitting and seeing some of the top DBA’s in the industry learning in sessions along with me…..yeah I was floored.
So my question today is a simple one; I had several topics to choose from technically but I’m curious as to what others think about our SQL Community. Not just some off the cuff answer but really what do you think about it and how has it helped you?
Below are some thoughts I had in creating this topic:
- How has the community helped me in my career
- How can I better the community
- How can I preserve what we already have
- How can I help other people in the community
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.
Invitation from Rob Volk.
n the beginning…
SQL Server has changed a lot since I started with it. <Cranky Old Guy>Back in my day, Books Online was neither. There were no blogs. Google was the third-place search site. There were perhaps two or three communityforums where you could ask questions. (Besides the Microsoft newsgroups…which you had to access with Usenet. And endure the wrath of…Celko.) Your “training” was reading a book, made from real dead trees, that you bought from your choice of brick-and-mortar bookstore. And except for your local user groups, there were no conferences, seminars, SQL Saturdays, or any online video hookups where you could interact with a person. You’d have to call Microsoft Support…on the phone…a LANDLINE phone. And none of this “SQL Family” business!</Cranky Old Guy>
Even now, with all these excellent resources available, it’s still daunting for a beginner to seek help for SQL Server. The product is roughly 1247.4523 times larger than it was 15 years ago, and it’s simply impossible to know everything about it.* So whether you are a beginner, or a seasoned pro of over a decade’s experience, what do you do when you need help on SQL Server?
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.
When we were kids, sometime during elementary school, adults started asking, “What do you want to be when you grow up?” The professions initially mentioned varied, but they were often along the lines of teacher, doctor, nurse, fireman, policeman, singer, engineer, etc. Obviously these are not the only professions in the world. There are so many different occupations that exist, that whenever I meet someone, I usually ask what they do. It’s not unusual for someone to list a title I’ve never heard (Improvement Coordinator is one I heard the other day). But a title doesn’t tell me what that person does. Even when someone’s a doctor or a teacher, there are so many variations nowadays that I always follow up with, “Well what do you do every day?” And I ask because I really want to know. So tell me…
This month’s T-SQL Tuesday post is about you and your job. Specifically, on Wednesday July 11th or Thursday July 12th, track what you do for an entire day and then write about it. Hopefully one of those days is a “typical” day and not a vacation day (if it is, then just pick another day or do your best), but ideally, everyone writes about what they did on one specific day.
The scope of this topic is wide open, you don’t have to simply list what you did – feel free to elaborate on what tasks you love or don’t love, your favorite or least favorite part of the day. Make the post as non-technical or technical as you want (maybe you learned something new that was really cool). My only request is that you list your official title, as I plan to include them in some way in my summary post.
I’m excited to be hosting this month’s T-SQL Tuesday. This month we’re talking about logging. Logging comes in many form and fashions. If you think about it, when you go to the grocery store with at big list, Do you put the items in the cart and then check them off the list? If so, isn’t that a kind of write-ahead log?
I point that out because I don’t want anyone to constrain themselves to talking about logging within just SQL Server. Please bring your ideas for file transfers, report generating, performance gathering, uptime monitoring and the like. But don’t stop there! This is an open invite to anyone that does anything in the SQL Server community.
If Karla Landrum ( blog | twitter ) wants to explain to us how on Earth she keeps track of all these SQL Saturdays around the world, that’s logging! If Tim Radney ( blog | twitter ) wants to tell us how he makes sure he keeps in touch with all of the chapters he’s responsible for as a PASS Regional Mentor, that’s logging!
How you keep track of blog ideas, white papers you read, or however it is you life-hack *your* SQL world: please share it with us!
I was in the first few months of my second database administrator job when the CTO told me that I needed to give the CFO direct table access into the database that I had designed. Not 3 months later we were having a company meeting so the executive staff could explain to the company that the CFO had stolen our client list and was out luring our customers away. Sound like a security issue? Not the way that I see it.
I had an ethics issue on my hands. From that day in 1997 I have always had my eye out for ethical issues, and more importantly looking for ways we can police ourselves. It does not take long for a new database professional to see that when you have access to data that there is going to be sensitive data in there somewhere. The obvious ones are the HR databases, or the financial databases that reside on our SQL Servers. But there are so many more areas that we need to look before we can get a good handle on how to solve these ethical dilemmas. Take a look at something that I posted a while back that threatened the security of the United States. I cannot imagine that it would take long for an ethical person to say, “Really?”
A few months ago I had to get a security clearance, and pass the Security + certification so I could do a short contract with the Air Force. As I was going over study material in a book I was supplied, I ran across a couple of short notes about ethics. I followed a link or two and I ended up here. When I first started to look at the list of ethics that they had listed, I was really impressed. As I got deeper into what they were saying I became a bit concerned, however. The company that produced this is a corporation, not an organization that has the best interests for the industry as a primary goal. I don’t believe there is anything wrong with being a for-profit, I know I work for one, and well, as an individual I am for-profit. My issues with the code is the code itself appears to be pointed and making the company a profit, at least it does to me. If that is the reason they sponsored the Code of Ethics, then well they violate their own ethics when they say:
“I will not advance private interests at the expense of end users, colleagues, or my employer“.
So here is where that leaves us:
For this month’s t-sql Tuesday question I wanted to highlight the need for Ethics in our industry. Don’t consumers and business owners have to trust someone at some time with their data? This month, take time to participate by talking about DBA ethics. I really hope to see someone address topics such as:
Should we have an ethics statement?
Have ethics issues impacted you? What did you do about it?
Security Audits: how do you police what you and others are doing in the database?
Does a Code of Ethics mean anything to anyone? How do we as a community enforce a Code of Ethics?
Do you have an issue with this Code of Ethics?
What do you believe our Code of Ethics should say if we the SQL Server Community have one?
Have fun, but take the time to dig deep and do some real soul searching. I know with large number of really smart professionals that we have in our community we can think of something. I will do up a summary once I have returned from my trip that week, but to be honest I hope this discussion goes on long after May 8th.
As with each of the T-SQL installments I ask that you follow some basic rules.
Yay!! It’s time for T-SQL Tuesday and this month I am hosting the party. I had another topic in mind when I asked to be a host but since the RTM occurred in March I thought it would be best to pick a topic focusing on SQL Server 2012!
I have been playing around with 2012 for some months now and I know for a fact that I don’t know all the new or improved features. As for the features that I actually do know, I cannot say that I am 100% sure that I fully understand all of the benefits that they provide. I don’t think that I am the only person who feels this way so I decided to pick a topic to help improve everyone knowledge of SQL Server 2012!
This month’s topic is: What do you think is a useful feature of SQL Server 2012?
The feature can be a new or an improved feature. I deliberately did not use the word ‘favorite’ to reduce the chance of multiple posts focusing on the same topic. I also deliberately used the word ‘useful’ to encourage bloggers to give detailed use cases and real-world examples. Remember these posts are to share knowledge and benefit the SQL community so if you want to ‘gain access to the VIP room at the After Party‘ then be the blogger who wrote about a useful feature that no one else covered.