Re: Bidirectional Binary Self-Joins

paul c <toledobythesea@xxxxxxxx> writes:
I knew one consulting company that charged an airline a lot of money
to do that. Eventually the effort was stopped when both parties were
asked to solve the "travelling salesman" problem in a most general
way, which was more or less what they were trying to do. The problem
was new to both parties, even to the airline's most experienced
business analysts! What's more, since that airline did a lot of
contracting out to other airlines, they wanted to include all airports
known to IATA, which numbered about 6,000 airports at the time.

The segment combinations that involved factorials also got the
consulting companies quite interested, suggesting schemas of hundreds
of tables for routing alone, let alone all the other stuff an airline
has to account for today.

re:
http://www.garlic.com/~lynn/2007g.html#22 Bidirectional Binary Self-Joins

some considered that we cheated ... in previous life I had been
involved in doing automated circuit layout ... and number of airports
and flight segments was a much smaller problem than typical circuit
layout problems ... the real trick was being able to do any possible
from/to in subsecond elapsed time (for all possible airports and all
possible flight segments)

bringing it somewhat back to database theory ... when i had been doing
some of the stuff on system/r
http://www.garlic.com/~lynn/subtopic.html#systemr

other refs
http://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object
http://www.garlic.com/~lynn/2007e.html#36 Quote from comp.object
http://www.garlic.com/~lynn/2007e.html#37 Quote from comp.object

i was also involved lending hand to some vlsi design tool group.
there was stuff like chip design, chip physical layout, board
layouts, circuit routing, etc.

the system/r group sort of took some optimizations with relational,
creating tables where the same schema was applied to everything in the
table. some types of chip stuff is very regular/uniform (say memory)
.... but other types of chips (processors) could be extremely
non-uniform.

so there was a joint project between the vlsi tools group and various
database people from STL (also where IMS went on) ... where all
relationships were bidirectional and physically instantiated. However,
instead of doing it as exposed record pointers (as in ims) ... it was
done as indexes ... ala the system/r metaphor ... but since there were
a huge number of (bidirectional, instantiated) relationships ... there
was also huge forest of such indexes.

this is the type of stuff that we use for the RFC index
http://www.garlic.com/~lynn/rfcietff.htm

and the various merged taxonomies and glossaries
http://www.garlic.com/~lynn/index.html#glosnote

.