Re: Bidirectional Binary Self-Joins

paul c <toledobythesea_at_oohay.ac> 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 Received on Sat Mar 31 2007 - 04:58:26 CEST