Re: Bidirectional Binary Self-Joins

JOG wrote:
> ...
> I hate the idea of having to invent a surrogate key to identify a
> game, just so that we can model it in RM (especially given it is
> perfectly identifiable from the date and teams). Hence using RVA's
> certainly seems preferable. But then we've added seemingly unnecessary
> complexity to our queries compared to:
> { (date:12-dec, team: Hope, team:Calvin) }
> { (date:12-dec, team: Hope, score 59), (date:12-dec, team: Hope, score
> 32) }
> Someone fix my thinking. quick.

I don't mean to sound like a Codd-worshipper, but I believe he intended to exclude RVA's. I think he also intended to require what I would "system-introduced" keys (using that term only because I don't like the baggage that today comes with "surrogate" and "artifical" in the eyes of many although not mine).

At the same time, I think rva's express some relationships more exactly.   I think Codd wanted a naive interface and that's why he avoided them as far as I know. For me, there is no doubt that this limits his model and I don't think "group/ungroup" solve the problem of coming up with an interface that could respect rva's without complication and subtler programmers and users. To date, I think the only possible solution is graphical, but not mathematical.

Not trying to change the example, which I think is excellent, but this reminds me of the airline game. In flight and related systems, it is enough to use airline code, flight number (an invented number), date, scheduled departure and arrival time in hours and minutes, departure airport code and destination airport code to indicate a flight (or flight segment, the term that biz uses). One could ask what prevents two different flights with that recorded key, from taking off from the same large multi-runway airport in the same minute? The answer is the key itself, which is embedded in every manual and computer method the controllers, airport personnel and so forth use, which doesn't include a runway code, nor anything close to scheduled times measured in seconds.

With more precise scheduled times, we might be able to eliminate artificial parts of that composite key, even the airline code for example. But how artificial is a key that a business embraces? How artificial is a bank balance expressed in dollars and cents rather than the concept of the client's net worth?

The long composite airline flight key is clumsy to use and sometimes there are convenient reasons to "indirect" it, say to re-assign cargo at the last minute, with yet another "artifical" key.

Just offering a counterpoint.

p Received on Sat Mar 31 2007 - 02:35:15 CEST