Category Archives: SQL

Understanding group bys

Yesterday, at work, it occurred to me, not for the first time, that something that comes so easily to me, does not to others.  I had tasked someone with, what seemed a simple task, to retrieve a list of users who have reached minimum payout.

The payouts were stored in a separate table from the users and users could have multiple payment records prior to reaching payout, thus we would need to use a SUM() on the amount.  Because we also required other data, we need to use a group by to properly sum the amounts a user has.

The task was handed back to me several hours later to review, it was quite evident that the main concept was “grasped”, but the understanding of group bys was not. Read more »

Share

CakePHP Containable Statement Pitfalls

On some of our more recent projects, we have been using the Containable behavior that CakePHP provides.  It works quite nicely, a lot easier than the previous format of having to bind and unbind models on the fly.

The pitfalls began to appear when some of our clients were reporting that some pages are extremely slow.  After a bit of research, it was quite apparent that the root of the cause was attributed to us using the containable feature. Read more »

Share

A practical CASE Statement Example

What is a SQL case statement? Well, it’s much like a switch statement in a development language. It allows you to test several different cases for a field and determine what you would like to do for each one.

If you have ever visited Mysql’s documentation, you may have been as lost as I was. You will find something like this:

CASE v
WHEN 2 THEN SELECT v;
WHEN 3 THEN SELECT 0;
ELSE
BEGIN
END;
END CASE;

If you are as confused as I was, let me provide you a better, more clear example. Read more »

Share

The Importance of Database Indexing

If you are not familiar with database indexes or even if you are, but not sure when to use them, this article will be perfect for you.

In this article, I will show you an example of a simple query without an index and then that same query again with the index.  I am certain that you will be shocked by the difference.

Read more »

Share

Dynamic COUNT() Versus Static COUNT()

I’ll continue today with another good database programming article.  If you missed yesterdays, you may view it here.

Today’s article will discuss when to use a static COUNT() versus a dynamic COUNT().  On a regular basis we are tasked with creating a message center or a photo album and we need to display a count of new messages or pictures in the album.

The obvious solution is to do a simple query: SELECT COUNT(*) FROM pictures WHERE album_id = 1 and display the result beside our album name.  Now, let’s assume that we allow multiple albums our actual query would be closer to this: SELECT albums.*, COUNT(pictures.*) as picture_count FROM albums INNER JOIN pictures ON albums.id = pictures.album_id WHERE albums.id = 1.  This will of course work, but let me show you a better, more practical approach that will improve performance significantly on large databases. Read more »

Share

Why You Should Avoid ORDER BY RAND() OR NEWID()

Quite often we get a complaint from a client that their homepage is too slow.  The first thing we do is load the homepage up and see for ourselves.  Yep, it looks slow, so the next step is too see what is being done.  Quite often you’ll see some random data being displayed on the homepage.  Whether it’s random news articles, photos, videos, etc…If this is not the case, you may find my article on improving slow loading web pages more useful.

If the homepage is slow because of random data, you can lay a bet with high certainty that those 10 random articles are being pulled with an ORDER BY RAND() OR NEWID() slowing the site to a crawl.  In case you are curious the difference, RAND() is the MySQL way and NEWID() is the SQL Server way.  In this article, I’ll show you why you should avoid these functions and several different solutions to help you overcome this issue. Read more »

Share

SQL Tips – Why LEFT JOINS are bad

When you do SQL queries do you find yourself always, or almost always, using left joins?  If you’ve answered yes to this question, I would suggest to continue to read and understand some downfalls that you might be getting yourself into.

Let’s start by looking at a standard query that has a left join:

SELECT * FROM users u LEFT JOIN countries c ON c.id = u.country_id WHERE u.id = 5

The following query will return all fields from the users table and all fields from the countries table.  Now you’re thinking, “Yeah, looks good, so what’s wrong with this?”.  Well, I’m glad you asked. Read more »

Share

Buy one of my books