# 30 - Searching with Joins

This page is part of the book SQL-99 Complete, Really, by Peter Gulutzan & Trudy Pelzer. The authors have graciously allowed us to reproduce the contents of the book here. Because the book is about the SQL-99 standard, the contents of this and other pages in the book may not directly apply to MariaDB. Use the navigation bar to navigate the book.

It's France in the 1600s. Rene Descartes is playing cards with Madame du Barry. The game is War. Each player has a deck. Rene plays a card from the top of his deck. Madame du Barry plays a card from the top of her deck. If Rene's card has a higher value then Madame's, he wins the trick. If his card has a lower value, Madame wins the trick. In the case of a tie, each player throws down another card. They repeat this until one player has all the tricks, or until Rene and Madame think of something more interesting to do (it's France in the 1600s).

In set theory, each trick is an ordered two-element pair. There are (52*52) possible first-round combinations. To honor Mr Descartes, we call the set of all possible tricks the Cartesian product of the two original (deck) sets. Two valuable insights arise from playing the game:

1. Insight: What matters is the values on the cards. There are no threads connecting the queens in Rene's deck to the queens in Madame's deck. There are no notes on each card saying "I match the nth card from the top in the other deck". There are, in other words, no pointers in the real world, we match based on values.
2. Insight: Slow, tedious meaninglessness. We recognize that there is always conceptually a Cartesian product, but we would like as quickly as possible to filter out the only interesting cases the ties (the 52*4 cases where the cards' face values are equal).

The first insight is the basis of relational-database theory. The second is a warning that we want to minimize the undesirable consequences of joined Tables.