Re: Impossible Database Design?

"David Cressey" <dcressey_at_verizon.net> writes:
> Back in the 1980s, I used to teach database programming and design
> in an industrial setting. The course was product specific, (DEC
> Rdb/VMS), but many of the concepts were not. I used to use the
> ariline reservation system as a classic example of why atomicity in
> a transaction was important. In my example, if your transactions
> can't be atomic, you can't prevent overbooking.
>
> Then one time, I got someone as a student who had been on the SAABRE
> project. He told me that they never did solve that poblem, but
> management decided that it was a feature and not a bug! I don't
> know whether I believe it, but it's an interesting fable anyway.
>
> More to the point, back in that time frame, the number of fare
> changes was about 10,000 per day. I expect it's much greater now.

recent post referencing rewriting major portion of one the airline res. systems (about a decade ago)
http://www.garlic.com/~lynn/2006j.html#6 The Pankian Metaphor

part of the issue was the paradigm had been established in the 60s and while things like scale-up had been done ... there hadn't really been any re-examination of the various design decision trade-offs established in the 60s ... and whether advances in technology might result in making other kinds of design decision trade-offs.

lets say there are around half-million take-off/landings a day (flight segments) and for round numbers there are 50 passengers per flight segment ... so you could have on the order of 25million updates per day (independent of changes in fares and schedules). that is besides possibly similar number of inserts of new PNR records for reservations and then similar number of deletes for old PNR records.

part of the issue is that there has been some amount of bookings where the person is no-show. somewhat as a result there tends to be some fine tuning of capacity planning attempting to get every seat filled, despite some percentage of no-shows.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/