Log Buffer #135

SELECT *
FROM user
JOIN user_pet USING (user_id)
JOIN pet USING (pet_id)

This works great for the most part, and also removes duplicate columns, as the columns used in the join are collapsed. So you can use the column name in a WHERE clause without having to specify the table:

SELECT *
FROM user
JOIN user_pet USING (user_id)
JOIN pet USING (pet_id)
WHERE user_id = 1

It’s a handy syntax for small simple queries.

Bitmasking is way cool though. As for SchizoDuckie’s comment. A real programmer should know a bitmask when he sees one, so I wouldn’t see it as a major issue. The problem is that many web developers aren’t real programmers, and have no formal training in programming (myself included). Sure, we should keep things simple, but in some ways, this is the simpler solution. Or maybe using SET is?

The power_of_two tables allows you quick lookups of the values instead of computing pow(2, x). You could also possibly add a check constraint on pet.id where the id has to be in the set of values available in power_of_two. It might be useful when calculating results for millions of rows – you wouldn’t want to calculate the power of 2 for each of those. But again, this works for very specific circumstances.

I wonder if you could explain the value of the ‘power_of_two’ table? That’s somewhat lost on me as, well, computers know that sort of thing already!

select u.username, sum(1 << p.id)
from user_pet up,
pet p,
user u
where up.user_id = u.id
and p.id = up.pet_id
group by u.username;

It is however somewhat less transparent and a (tiny) little more computationally intensive, but then again, using exclusively powers of two as keys in order to be able to generate bit masks isn’t that transparent either :-p. If you really want your keys to remain under 32, you can always use a checks, triggers, or a relation containing the numbers 0 till 31 for that of course.

Also, I’m wondering about one thing, as you mentioned

“… And now that person has all pets. And you didn’t even have to check if they had them before! Hooray for bitmasks!”

As this post is about database design, I’m wondering whether this is about assigning pets to a user in the database or, temporarily, in the application. (Of course, storing the user-pet relation in a bit mask itself and dropping the user_pet relation would yield poor performance when searching for other cat lovers :-p.)

Finally, I must say I have to agree with SchizoDuckie on the particular use. Although it can be beneficial in some cases (small sets)… If you’re going to have to cache values anyways I’d rather go for offline aggregating (and even offline joining) to get some performance increase, rather than adapting the database design to a solution which isn’t really suited for further growth (in case of adding more animals, that is :-). But for the “some cases” I think the ability of using bit masks with the combination of normalization (perhaps a little de-normalization) is pretty elegant.

As for the problem you mention, some time ago I bumped into a strange when I upgraded an application to MySQL 5 and if I’m not mistaken, from 5.x on MySQL forces you to use parentheses precisely to prevent that ambiguity (the error I was seing was due to a JOIN that didn’t have the parentheses, if I recall correctly). But yes, it’s a perfectly valid concern.

I thought about the size of the result set, too, but I guess that even with a small result set even a small performance gain can be advantageous when you’re dealing with an application that has a high volume of traffic from the database – in other words, if the query gets executed a lot in a small amout of time.

The result set is very small, so any performance considerations go out the window (although now I’m curious about the performance benchmarks on inner join vs. natural join implementations across the common databases!)

I’ll see if WordPress enables comment preview!

Also, for this to work, column names had to be consistent across tables. That is, the “id” column in both the “user” and the “pet” tables should be named “user_id” and “pet_id”, like the columns in the “user_pet” table.

Specifically, the last query you wrote before introducing the bitmask change, would be this:

SELECT username, group_concat(name)
FROM user NATURAL JOIN user_pet NATURAL JOIN pet
GROUP BY username;