NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/database/6128

Internet Message Format | 1992-08-14 | 4.5 KB

Xref: sparky comp.databases:6128 comp.databases.theory:362
Newsgroups: comp.databases,comp.databases.theory
Path: sparky!uunet!gatech!darwin.sura.net!mips!sdd.hp.com!ux1.cso.uiuc.edu!mp.cs.niu.edu!higgins
From: [e-mail] (Greg Higgins)
Subject: Re: Relational Queues
Message-ID: <[e-mail]>
Organization: Northern Illinois University
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 14 Aug 1992 20:24:06 GMT
Lines: 86

In article <[e-mail]> mfriedma@uucp (Michael Friedman) writes:
>In article <[e-mail]> [e-mail] (Greg Higgins) writes:
>>In article <[e-mail]> mfriedma@uucp (Michael Friedman) writes:
>>>In article <[e-mail]> [e-mail] (Jonathan Edwards) writes:
>>>>How do you implement a standard FIFO queue in the relational model?
>
>>>>Here's the rules: multiple producers, multiple consumers. No possibility of
>>>>two consumers getting the same record. Ability for consumer to wait if the
>>>>queue is empty (no polling allowed!). Strict FIFO, but to make it a little
>>>>easier, I only ask that a record enqueued by one transaction come before all
>>>>records enqueued by other transactions that START after the first one COMMITS.
>
>>>>I believe that this can only be done by setting up a central server program,
>>>>called from the producers and consumers (perhaps via RPC), which serializes
>>>>access to the relation representing the queue. If this is true, doesn't anyone
>>>>else find this a rather glaring weakness?
>
>>>The SQL standard supports sequences.  Just create an increasing
>>>sequence and use it to number each item you add to the table.  Then
>>>when you pop items off, just select where SEQ_NUMBER = MAX(select
>>>seq_number from table).
>
>>Hardly. This implements a LIFO queue.
>
>Sorry.  Momentary attack of braindeadness.  Just replace MAX with MIN.

The guy next to me is working on MIN; I want MIN + 1, but then so
do the other 20 people in the room.

>
>>>In general, however, this wouldn't even be a weakness if we didn't
>>>have a solution.
>
>>>SQL is intended to solve real world problems, not comp sci questions.
>>>If you don't have the information in your database to know which item
>>>in your list should be dealt with next then either you didn't design
>>>your database right or it doesn't matter which comes next.
>
>>Wanting a FIFO queue is not just a comp sci problem. It is a real world
>>problem, and one which application developers need to deal with frequently.
>
>>Consider a help desk situation where you have a first line tech support
>>screening calls, entering them into the database, and then putting the
>>folks who need more help on hold for second level support.
>
>>You want second level support to pick up those call in the correct order.
>
>>Note that the correct order may not be the serial number, since presumably
>>that would be the initial entry into the database by the first line support.
>
>So what is the correct order?  Probably it's the order in which they
>were put on hold for second level support.  So how would I handle that
>if I didn't have sequences?  Hmm.  Well, would a timestamp do?  Yup.
>And if you don't have a time stamp you didn't design the database
>right.
>
>SQL has its limitations (explosion of parts, for one) but this isn't
>one of them.
>
>>>I am not an official Oracle spokesman.  I speak for myself and no one else.
>
>>I'll bet Oracle Corp. is glad of that. You should consider
>>solving the problem instead of criticizing the presenter
>>and maybe that will change.
>
>Yow!!!!  Actually, even reading over my original post, I didn't think
>it was in any way mean.  As far as criticizing the presenter goes, I
>think that for posts like this, where someone is debating an issue, as
>opposed to asking "I need help" it is acceptable to post
>counterarguments.  I guess some people consider that to be criticizing
>the presenter.  I don't.

"comp sci questions" is vendorese for "Shut up, buy my product, and we'll
figure out later if it can actually do the job." I've heard it a lot,
especially from representatives of a large, well known database
vendor. If put to me when I'm in the right mood, as I apparently was
the other day, it gets my dander up.

>
>Mike
>
>--
>-------------------------------------------------------------------------------
>I am not an official Oracle spokesman.  I speak for myself and no one else.