home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6171 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  2.9 KB
  1. Xref: sparky comp.databases:6171 comp.databases.theory:370
  2. Newsgroups: comp.databases,comp.databases.theory
  3. Path: sparky!uunet!decwrl!world!edwards
  4. From: edwards@world.std.com (Jonathan Edwards)
  5. Subject: Re: Relational Queues
  6. Message-ID: <Bt6K3v.GrA@world.std.com>
  7. Organization: The World Public Access UNIX, Brookline, MA
  8. References: <1992Aug13.195729.19884@oracle.us.oracle.com> <1992Aug14.202406.17593@mp.cs.niu.edu> <1992Aug16.062239.24049@oracle.us.oracle.com>
  9. Date: Tue, 18 Aug 1992 12:59:55 GMT
  10. Lines: 47
  11.  
  12. In article <1992Aug16.062239.24049@oracle.us.oracle.com> mfriedma@uucp (Michael Friedman) writes:
  13. [proposal to handle FIFO queues, particularly the dequeue operation, by
  14. putting various tag columns into a relation]
  15.  
  16. Let me complicate the problem, by requiring TRANSACTION CONTROL of all
  17. queue operations. Pretend that these queue entries are your paycheck being
  18. direct-deposited [thats actually what my systems are used for]. So you want
  19. to be able to dequeue from one queue and process the entry all as part of a
  20. standard database transaction. Transactions eliminate the ability to use tags
  21. to declare that certain entries are 'pending dequeue' as you propose.
  22. How do I do an efficient dequeue operation that is transaction protected
  23. and scales up to dozens of pending dequeues?
  24.  
  25. As far as I can see, there is no PRACTICAL way to do this in straight SQL.
  26. Someone mentioned that PROGRESS' language can search for unlocked records.
  27. And no one yet has addressed the issue of how to WAIT on an empty queue,
  28. other than periodically polling, which (technically speaking) sucks.
  29.  
  30. >
  31. >Well, considering that SQL is pretty much standard between Oracle and
  32. >all of our significant competitors I'm not going to run arround
  33. >making a fuss about how SQL can do the job.  It's an industry
  34. >standard and we don't need to defend it any more.
  35.  
  36. Weak, weak. "Industry Standard" translates to: "Gee, software is just too
  37. complicated to sell, so lets all agree on some simplistic solution and
  38. claim that doing things the right way is actually wrong, because its
  39. non-standard. We can sell a lot more software that way."
  40.  
  41. >
  42. >As for "comp sci questions" versus real word questions, I really do
  43. >believe there is a difference.  I'll admit that you've given a pretty
  44. >good example of a need for a FIFO queue, but in the vast majority of
  45. >applications you really don't need one.  [...]
  46.  
  47. Speak for your own real world applications. The ones I have been building
  48. for fifteen years REQUIRE queues. I suspect that if
  49. relational databases supported queues, they would be found to be widely
  50. useful. IMAO, relational databases will eventually be seen as a mass
  51. delusion, since they are not anywhere close to being a useful data model
  52. for the vast majority of applications. How many wordprocessors or spreadsheets
  53. or compilers or file systems use the relational model for their data?
  54.  
  55. Jonathan Edwards
  56. IntraNet, Inc.
  57. I DO speak for my company!
  58.  
  59.