ON THE RED/BLUE MIND PROBLEM
with Fabian Pascal

 

 

 

From: Perry Valdez

Date: 18 Mar 2006

 

I just want to share with you the so-called "red/blue car problem", which was introduced by Albert D. Kallal, a supporter of MV, in the May 2003 SQL vs. MV debate in comp.databases.theory. Kallal also gave a link to his December 2001 article about MV. The link is now dead, but there is an  archived version. The "red/blue car problem" is referenced in the Relational and Multivalue Databases (a.k.a. Evidence for Wolthuis) at dbmonster.com/Uwe/Forum.aspx/db-theory.

 

Anyway, here's the "red/blue car problem", as stated informally by Kallal (see Reply #9):

 

"Find a salesman who sold a blue and a red car."

 

Celko attempted to formulate the query using SQL; unfortunately he got the answer wrong. [Ed. Note: I am not surprised. That’s typical of Celko. The combination of him and SQL is lethal.]

 

The red/blue car problem is really a very trivial question; unfortunately it's a bit complicated to formulate it in SQL. When I tried to answer this problem, I found it easier to think in terms of sets than think in SQL directly.

 

Here's my solution. First, I restated the problem in more precise terms.

 

Problem: Find a salesman who sold a blue and a red car. Restated version: Find all sales reps who have a history of selling BOTH blue cars AND red cars.

 

Next, I defined my relations

 

Here's my actual SQL code for the table definitions (using PostgreSQL 8.0.7)

 

In SQL, it's this

 

This whole SQL code is actually executable in PostgreSQL 8.0.7. I developed another equivalent formulation based on the above query

 

 

From: Fabian Pascal

 

What is your point?

 

1.      Stating some query without any reference to some detailed conceptual and logical model representing the universe of discourse is meaningless.

 

2.      SQL is not any evidence against the relational model.

 

3.      One specific query is not a proper comparison between data models. I describe what a valid comparison takes in Conceptual Modeling and Database Design.

 

Responding to an issue like Kallal’s is falling into the "trap" that MV people create by their limited understanding of data fundamentals.

 

Ed. Note: The replies to Kallal in the exchange make it quite clear he doesn't know data fundamentals and what he's talking about. He accuses others who do know as being closed minded, which is exactly what he is, judging from his failure to understand the replies to others' explanations.]

 

 

From: Perry Valdez

 

But isn't any database query supposed to be easier to formulate in a truly relational data language than in SQL or an MV language (e.g., PICK)?

 

 

From: Fabian Pascal

 

In general yes, but picking some query and particular simplistic design is not the way to prove it. Anybody can contrive conceptual situations to prove whatever point he wants. That is why a comparison must be sound, systematic, and complete. Read my paper Conceptual Modeling and Database Design.

 

Besides, ease of query formulation is by no means the only advantage of the relational model [what about soundness, data independence, no database bias, and so on?]. If you read my papers, one of the problems with MV people is that they stick to structure and ignore manipulation and integrity altogether. That’s why MV "DBMSs" can be made to seem “more productive”.

 

I said my piece about MV in What First Normal Form Means Not and several exchanges on the site. There is nothing that the likes of Kallal or anybody else (like that idiot Youngman) can say that warrants further comments.

 

 

Posted 5/5/06

© Fabian Pascal 2000-2006 All Rights Reserved