A moving time…

For those of you who read my blog using RSS, you probably won’t even see this post, but either way. I’ve decided to move my blog to sqlblog.com. I have reposted some of my recent posts, but will not be posting any further content here at msmvps.com. Both the feed from msmvps.com and sqlblog.com use feedburner.com, so the old feed will continue working, but I recommend changing to the new one in case my blog disappears from msmvps one day. So farewell, msmvps.com (and thanks Susan!), it’s been fun. I’m sure I will still have many posts which link back … Continue reading A moving time…

T-SQL Tuesday #003 (Relationships): The round-up

Lots of blog posts for this month, for the first T-SQL Tuesday to leave the safe-haven of Adam Machanic’s blog. Some people obviously missed out, probably because they don’t read this blog, but I guess that’s the nature of the meme. I don’t know who is hosting next month yet, but I’ll be looking out for Adam to post something about it in early March. All the posts had to appear as trackbacks or comments on the invitation to participate, but this post is a short summary for posterity. As the second week of February involves Valentine’s Day (and a … Continue reading T-SQL Tuesday #003 (Relationships): The round-up

The Query Optimizer’s handling of Relationships for T-SQL Tuesday #003

I’m feeling the pressure for this month’s T-SQL Tuesday, probably because I’m also the host. I’ll be posting a roll-up for it soon too, which I’m sure will be great fun researching. Given that the topic is on relationships, and the main SQL Server database is a relational engine, relationships are incredibly relevant to databases. The idea behind RDBMSs is that keys are used to refer to entities. This leads to foreign keys, such that a particular column(s) is constrained to values which appear in another table, thus referential integrity is enforced. And yet there are so many database designs … Continue reading The Query Optimizer’s handling of Relationships for T-SQL Tuesday #003

Invitation for T-SQL Tuesday #003: Relationships

It’s time for the third of Adam Machanic’s T-SQL Tuesdays, and this time, I’m the host. The first one, last December was on the topic of date/time, and the second was on Puzzling Situations. Check them both out, along with the round-ups that Adam wrote about them. Lots of great topics, which is starting to make me anticipate the content that comes out on the second Tuesday of each month. As an early volunteer to host, I have been given the honour of being the first person chosen to host one. I’d like to claim that this implies some sort … Continue reading Invitation for T-SQL Tuesday #003: Relationships

A CASE study in SARGability

A recent discussion on Twitter about a query that Denny Cherry was looking at led to this post by Josef Richberg: http://josef-richberg.squarespace.com/journal/2010/1/28/is-a-case-statement-considered-sargable.html, and I thought it might be worth going through a few points on the topic of SARGability. Particularly given that I wrote a related post recently myself. If something is SARGable, it means it can be used as a Search Argument – that is, it can be used effectively in conjunction with an index. To repeat a common analogy, trying to find “Farley” in the phonebook is a Seek (I can pretty much go straight there), whereas trying … Continue reading A CASE study in SARGability

SARGable functions in SQL Server

SARGable is an adjective in SQL that means that an item can be found using an index (assuming one exists). Understanding SARGability can really impact your ability to have well-performing queries. Incidentally – SARGable is short for Search ARGument Able. If you have an index on phone numbers using LastName, followed by FirstName, including the suburb and address fields, you have something akin to the phone book. Obviously it becomes very easy to find people with the surname “Farley”, with the first name “Rob”, but often you want to search for people with the surname “Farley” with the first name … Continue reading SARGable functions in SQL Server

T-SQL Tuesday – HAVING Puzzle answer

Earlier today you may have seen a blog post of mine about a puzzle involving HAVING. You should read that post before this one. It was part of Adam Machanic’s T-SQL Tuesday meme. The question was about the query: SELECT ‘No Rows’ WHERE 1=2 HAVING 1=1; And here’s the explanation. Start by making yourself a "dual table", like what you’d use in Oracle, and use this instead of having no FROM clause. Put a row in it. CREATE TABLE dual (dummy bit); INSERT dual VALUES (1); –Now count the rows in it SELECT COUNT(*) FROM dual; –Now count how many … Continue reading T-SQL Tuesday – HAVING Puzzle answer

T-SQL Tuesday – T-SQL Puzzle with HAVING

Adam’s hosting another T-SQL Tuesday, for which this post is jumping in. He’s themed it around T-SQL Puzzles, which I found quite interesting, because the world is full of them. Most of the questions that I answer on forums, help sites, and so on, are puzzles. I guess there’s the difference between “Problem” and “Puzzle”, but I prefer to think of thing as puzzles. For Adam’s meme though, I thought I’d share a Puzzle that I ask students who take my Advanced T-SQL course. The idea is to have them start thinking about what each component of T-SQL is actually … Continue reading T-SQL Tuesday – T-SQL Puzzle with HAVING

Foreign Keys against Views

Foreign Keys are great. For those of you who read some of my other posts, or heard me present on this material before, a foreign key can really help the Query Optimizer simplify out your query, because it knows that it must be able to find a match in an equality join (unless the field allows NULLs, which is a whole nother story). I also blogged recently about the fact that a foreign key doesn’t have to reference the primary key of a table. Turns out it can reference any candidate key, that is, one that has a unique index … Continue reading Foreign Keys against Views

Apostrophes around column aliases

Far too often I see SQL code which uses apostrophes around column aliases, like this: SELECT ProductID, SUM(LineTotal) AS ‘Total’ FROM Sales.SalesOrderDetail GROUP BY ProductID; This is fine, but the worrying thing about this is if the user decides to use this alias in an outer query. SELECT ‘ID’, ‘Total’ FROM ( SELECT ProductID AS ‘ID’, SUM(LineTotal) AS ‘Total’ FROM Sales.SalesOrderDetail GROUP BY ProductID ) AS p ; Here, the outer query will assume that ‘ID’ and ‘Total’ are strings, not the names of columns in sub-query. It’s really not pretty. The query runs, but doesn’t give the correct answers. … Continue reading Apostrophes around column aliases