Who Do I Follow? Where Do I Go?

There are many helpful sites within the SQL Community and several more blog sites that I follow. My favorites are noted on this site; however one that keeps drawing me back time and time again is by Brent Ozar’s group. For those of you who have not had the opportunity to check the site out I’ll lay out some real world specifics on what has helped me and how I have benefited from such sites as this one.

The Webcast’s

Every Tuesday I usually find my way to their 30 minute webcast for treating pain points within SQL (among other topics). At the end of each web cast, if time permits, they will host a quick question and answer session over the topic to viewers. Check out future webcast’s here

Two Important Free Tools

There are two scripts that have seemed to help me tremendously over the course of the year. One is sp_Blitz (comes with a SSMS custom report) which a new version just came out; and the other is sp_BlitzIndex. I recently just started to use the sp_BlitzIndex but I liking this little utility while the other sp_Blitz I use when hitting new or old servers, you know the ones that you stumble upon that no one knows about and no one has a clue of what it is doing. Two great free utilities that are offered that may just save your hide one day.

Popular Topics

I like the fact that on the site they keep a section for Popular Topics that are happening within the industry; keeps me up to date and provides insight on some of the issues I experience on a daily basis. Some topics you may find:

The Team

The team makeup of Brent, Kendra, Jeremiah, and Jes makes it an easy choice for me to have in my arsenal of following. I try to find people in the industry of whom I consider for myself top in the industry and learn from them and their techniques to help better myself and further gain more knowledge.

Check it out

If you haven’t already done so go check their site out and what their about. Real people providing real solutions with some fun along the way.

T-SQL Tuesday #37: Invite To Join Me In a Month of Joins

TSQL2sdayThis month’s T-SQL Tuesday is being hosted by Sebastian Meine (blog | twitter) and his topic is anything and everything about “joins”. He’s dedicted the whole month of December to this topic.

Having had the opportunity to do extensive SQL work as a developer when first starting out I have been accustomed to joins for some time. Joins are one of the basic constructions of SQL and Databases as such – they combine records from two or more database tables into one row source. Depending on join type and join restrictions returned row count can be from 0 till all possible combinations of involved tables. Databases are built to make joins as efficient as possible. It means almost always joining data in database is more efficient than doing that somewhere else. It also means one has to know the power and possibilities of joins to fully exploit their strength.

Types of Joins

These are the most common joins that I have ran into:

  • INNER JOIN – only rows satisfying selection criteria from both joined tables are selected.
  • LEFT OUTER JOIN – rows satisfying selection criteria from both joined tables are selected as well as all remaining rows from left joined table are being kept along with Nulls instead of actual right joined table values.
  • RIGHT OUTER JOIN – rows satisfying selection criteria from both joined tables are selected as well as all remaining rows from right joined table are being kept along with Nulls instead of actual left joined table values.
  • FULL OUTER JOIN – rows satisfying selection criteria from both joined tables are selected as well as all remaining rows both from left joined table and right joined table are being kept along with Nulls instead of values from other table.
  • CROSS JOIN – A cross join performs a cartesian product on the tuples of the two sets.

Usually cross joins are used quite rarely; some of the scenarios could be as follows:

  • Possibility to generate high amount of rows. As we can see from relatively small tables there is possibility to get quite monstrous numbers.
  • Find out all possible row combinations of some tables. Mostly this is useful for reports where one needs to generate all combinations for example all nationalities x genders for persons.
  • To join a table with just one row. Most often used to get some configuration parameters.

ALIAS JOINING

Some other questions I’ve been asked over the years is proper aliasing. I’ve had people use the a,b,c, method and a short table def. for example:

Example 1

Select *

from table 1 a (nolock)

inner join table 2 b on a.id = b.id

Example 2

Select *

from customer cust (nolock)

inner join address adr on cust.id = adr.id

The Performance

I’ve seen queries astronomicaly long with nasty subselects, joins, union alls, etc. Alot of times in my query tuning and looking at poorly designed queries, stored procedures, udf’s etc it is quickly seeable whether joins are being used correctly or incorrectly. When one takes the proper time to review the database and the schema and then build the queries with powerful joins performance can be quite optimal.

Future T-SQL Tuesdays

I urge you to take the time to check out Sebastians site and hey while I’m at it if you feel like you want to host a T-SQL Tuesday give Adam Machanic a shout. I can tell you from experience that I’m glad I did. Getting involved is a great way to get going with the SQL Community and the SQL family.

Thanks Sebastian for hosting this month!

Give Credit Where Credit Is Due

Should I give credit?

We’ve all been there; it’s late in the day and you have been staring at your screen for hours on end looking for an answer to your problem. After much testing; going back and forth you stumble upon an article on a technical website, blog, or Microsoft site that has the answer you have been looking for.

What’s Next?

As you look at the article and you implement the code that has been found you find that it works like a champ; your problem has been solved and crisis has been averted. Your colleagues come running up to you shaking your hand telling you that you are the greatest SQL DBA super hero that has ever lived, the boss comes over and pats you on your back and tells you that you are well on your way; all the while you never pipe up and say “Hey, I found this at…..”

The Reality

Okay maybe it doesn’t quite get that out of control but you get the picture. The temptation is there to take glory for something that you didn’t write or produce. Sure you’ve found the solution to the problem by doing hour of research but does one really take the time out of the high-fiving, chest bumping to note how you came up with the resolution?

Give Credit Where Credit Is Due

Here lately I have been on several technical blogs, had conversations where credit is taken for work that was done by someone else. I’ve seen it among teams, I’ve seen it nationally, and I’ve seen it accidentally. One thing that I enjoy about the SQL Community is that everyone is so helpful to provide assistance to others who are in need of help or need assistance in understanding an issue that they are working on. In saying that I believe it is of the utmost importance that if something is utilized that someone else has mentioned, wrote, helped with that you give credit where credit is due.

What Can I Do?

One might ask, how do I give credit to someone I don’t even know…….to me this is the most simplest of things. I’ve never met a person when I’ve approached them and asked them that I would like to mention them in my post about the tool, code, or article they produced turn me down.

I believe it is a way to show respect to our colleagues and to our community…..

I believe it is a justice that we must take on as a responsible SQL DBA……

I believe it is proper etiquette to display……..

Have you ever had a utility, piece of code, article that you created only to find out later that someone took credit for it? I implore others who may come across this article to take a step back and give others credit where credit is due. You’ll be glad you did and at the end of the day just be honest.