Re: Impossible Database Design?

"Jay Dee" <ais01479_at_aeneas.net> wrote in message news:%04bg.26699$YI5.6989_at_tornado.ohiordc.rr.com...
> Nikolai Onken wrote:
> > I didn't tell you yet:
> > I wanted to go to buy tickets to Israel today and guess what..
> > Inbetween the time our agent called her agent to find out the price and
> > the call she made to confirm the flight after we decided that it was
> > the right flight the price of the flight raised by 6 percent... yeah
> > the guys who have writte that kind of software must have had a good
> > imagination of time and sense.
>
> [You're stepping on my toes, today...]

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. Received on Fri May 19 2006 - 16:10:49 CEST