DotNetKicks.com : Stories kicked by jimrice14

UNPIVOT: Normalizing data on the fly

Tue, 29 Apr 2008 19:59:18 GMT

Everyone seems to want to "pivot" or "cross tab" data, but knowing how to do the opposite is equally important. In fact, I would argue that the skill of "unpivoting" data is more useful and more important and more relevant to a SQL programmer, since pivoting results in denormalized data, while unpivoting can transform non-normalized data into a normalized result set.

Simple DataViewReader class that implements IDataReader for a DataView

Thu, 28 Feb 2008 15:44:03 GMT

I previously wrote that the DataTableReader class is really handy, but unfortunately there is no DataViewReader class. So, I wrote one.

Some SELECTs will never return 0 results -- regardless of the criteria

Tue, 13 Nov 2007 16:17:24 GMT

In SQL, the general rule of thumb is that the number of rows returned from a SELECT will be zero if your criteria did not match any data. However, there is an important exception to this rule; it does not apply when asking for aggregate calculations such as SUM(), MIN() or MAX(), without any grouping. This is rather interesting and important to know and look out for, as it can cause some confusion and recently some of my ASP.NET code failed due to this. Let's take a look.

Splitting a single DataTable into Parent/Child DataTables for Hierarch

Fri, 02 Nov 2007 17:04:16 GMT

A simple function in C# that takes a single DataTable and creates a related parent DataTable in the same DataSet based on specified parameters. This is useful if you only have a single result set from SQL (or any other data source) and you'd like to break that data up into two separate parent-child DataTables in order to use nested repeaters or any other type of parent-child processing on the data.

Taking a look at CROSS APPLY (SQL Server 2005)

Tue, 23 Oct 2007 18:47:25 GMT

I think the easiest way to think of CROSS APPLY is that it is like doing a CROSS JOIN with a correlated sub-query instead of a derived table. Let's take a look ....

Avoid Mixing INNER and OUTER Joins in SQL

Fri, 12 Oct 2007 16:16:03 GMT

I had previously written about the danger of Criteria on Outer Joins, but recently another situation popped up that occasionally causes issues with OUTER JOINS that I thought I might address. The issue is when you have multiple tables joined in a single SELECT, and you mix OUTER and INNER JOINS together. The end result doesn't always seem to "work", and it can be tricky to understand exactly why and how to fix it without incurring additional unintended side effects.

Creating CSV strings in SQL: Should Concatenation and Formatting Be Do

Tue, 09 Oct 2007 19:50:30 GMT

A question I see very often in the SQLTeam forums is how to return data in a somewhat summarized form by concatenating multiple values into a single CSV columns. This can be done fairly easily in T-SQL, but as the formatting and concatenation requirements becomes more elaborate, be sure to ask yourself: Am I forcing presentation code into the database layer?

.Net: Passing user data with Exception back to the caller method

Tue, 25 Sep 2007 06:31:01 GMT

A simple way of passing any user data in the Exception back to the caller method.

Conditional WHERE Clauses: Avoiding ORs and CASE Expressions

Wed, 19 Sep 2007 17:01:01 GMT

Some tips regarding optimizing your SELECT statements when using conditions in your WHERE clause based on optional parameter values.

Working with Date-Only and Time-Only data in SQL Server

Thu, 30 Aug 2007 11:01:02 GMT

It's all about using the right data types. Sure, there's no "date" or "time" only data type available, but that's no excuse to return VARCHAR strings formatted as dates or times instead of the correct data type: datetime.

Don't forget about composite primary keys -- many programmers do!

Fri, 24 Aug 2007 02:46:02 GMT

When you define more than one column as your primary key on a table, it is called a composite primary key. And many experienced and otherwise talented database programmers have never used them and may not even be aware of them! Yet, composite primary keys are very important when designing a good, solid data model with integrity.

The problem isn't the poor database model; It's that external code is

Wed, 15 Aug 2007 14:01:02 GMT

Dealing with poorly designed databases is a simple and common fact of life for programmers. It happens, sometimes due to lack of experience or education, or sometimes because business requirements were never analyzed properly or they changed. It's hard to avoid poor database designs, but it takes only a simple concept to make fixing those designs much easier.

But WHY Must That Column Be Contained in an Aggregate Function or th

Mon, 23 Jul 2007 00:31:02 GMT

Column 'xyz' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause. Arggh!! There it is, yet again .. that annoying error message. Why is SQL so picky about this? What's the deal!?

The "Nested WHERE-IN" Anti-Pattern

Thu, 12 Jul 2007 11:01:01 GMT

There's a fascinating technique that I see many beginners use when writing SQL statements, and I call it the "Nested WHERE-IN" anti-pattern. It is, unfortunately, a common SQL technique used to avoid JOINS at all costs.

Data Types -- The Easiest Part of Database Design

Tue, 03 Jul 2007 07:39:31 GMT

I see it time and time again in forums -- "dates" that don't sort properly, "numbers" that don't sort or sum() correctly, made up "boolean" conventions that are difficult to work with, and so on ... Of course, without a schema or DDL to see, it sometimes takes many posts going back and forth until we finally realize: "wait ... you aren't using a datetime data type to store these dates???"

Passing Arrays or Tables as Parameters to a Stored Procedure

Thu, 28 Jun 2007 07:16:01 GMT

SQL Server has everything you need already in place to accept large, complicated sets of data as parameters in a stored procedure!

Passing Arrays or Tables as Parameters to a Stored Procedure

Tue, 26 Jun 2007 05:45:53 GMT

SQL is a set-based language, and often we wish to pass sets of data as a parameter to a stored procedure. For example, you might wish to pass a set of Customers to an invoice generating stored procedure, or a set of employees which for you'd like to calculate a particular bonus. There doesn't seem to be an easy way to accomplish this in T-SQL, but here's a simple technique that you might want to look at.

What I learned about SQL from using Access

Thu, 14 Jun 2007 07:05:10 GMT

Microsoft Access / JET SQL doesn't support cursors; the only way to process rows one by one is using VBA and opening a Recordset. This means that you're stuck using set-based "queries". So ... is this a good thing or a bad thing? A very, very good thing -- in fact, it's what makes Access a great tool for learning SQL!

Data Modeling: Don't Let Output Dictate your Design

Tue, 12 Jun 2007 05:51:27 GMT

I often talk about "database layer" versus "presentation" layer, but even the within just the database layer it is important to understand that how the data is physically stored does not always have to correlate with how the database returns results. There is still room for your SQL statements to use Views, Stored Procedures and User-Defined Functions to occasionally transform your well designed, clean normalized data into something that is easier for reporting tools to consume -- especially if those tools are used by clients who don't have strong skills.

Why to avoid FULL OUTER JOINS -- and what to use instead

Thu, 31 May 2007 05:01:01 GMT

Using FULL OUTER JOINS results in sloppy, inefficient SQL, with no true structure and NULLS in potentially every column in the results. Here's some better ways to write your SELECT if you think you might need to use a FULL OUTER JOIN.

Real Programmers don't need to write test applications!

Fri, 25 May 2007 08:01:01 GMT

Expert, experienced, enterprise-level programmers (the 3 E's!) simply don't have the time or the need to write silly little test programs to try out new techniques, right?

Criteria on Outer Tables in SQL -- beware of this situation!

Mon, 14 May 2007 06:29:07 GMT

When using an OUTER JOIN, you should put criteria on the outer table in the join condition, not in the WHERE clause. However, I often see a "workaround" to avoid this simple and solid rule, which might seem to work but actually doesn't. Since it is hard to explain why over and over in forum posts, I thought it might be helpful to address that here once and for all with an example.

Biggest difference between Temp tables and Table variables in Sql Serv

Wed, 16 May 2007 09:31:01 GMT

One of the most important differences between Temp tables and Table variables is how they behave in transactions. See how.

Thinking set-based (in SQL)

Wed, 09 May 2007 08:46:01 GMT

Are you really a "set based sql master" ? Maybe not. Don't forget that the key lesson you've learned from your procedural programming experience still applies!

MS Access to SQL Server cheatsheet

Tue, 17 Apr 2007 11:31:55 GMT

If you work with both MS Access and SQL Server, or if you must do conversions between the two, this handy guide gives a recap of the differences between the two SQL dialects.

DotNetKicks.com : Stories kicked by jimrice14

UNPIVOT: Normalizing data on the fly

Simple DataViewReader class that implements IDataReader for a DataView

Some SELECTs will never return 0 results -- regardless of the criteria

Splitting a single DataTable into Parent/Child DataTables for Hierarch

Taking a look at CROSS APPLY (SQL Server 2005)

Avoid Mixing INNER and OUTER Joins in SQL

Creating CSV strings in SQL: Should Concatenation and Formatting Be Do

.Net: Passing user data with Exception back to the caller method

Conditional WHERE Clauses: Avoiding ORs and CASE Expressions

Working with Date-Only and Time-Only data in SQL Server

Don't forget about composite primary keys -- many programmers do!

The problem isn't the poor database model; It's that external code is

But *WHY* Must That Column Be Contained in an Aggregate Function or th

The "Nested WHERE-IN" Anti-Pattern

Data Types -- The Easiest Part of Database Design

Passing Arrays or Tables as Parameters to a Stored Procedure

Passing Arrays or Tables as Parameters to a Stored Procedure

What I learned about SQL from using Access

Data Modeling: Don't Let Output Dictate your Design

Why to avoid FULL OUTER JOINS -- and what to use instead

Real Programmers don't need to write test applications!

Criteria on Outer Tables in SQL -- beware of this situation!

Biggest difference between Temp tables and Table variables in Sql Serv

Thinking set-based (in SQL)

MS Access to SQL Server cheatsheet

But WHY Must That Column Be Contained in an Aggregate Function or th