home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / informix / 1713 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.8 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!sun!amdcad!weitek!pyramid!infmx!proberts
  2. From: proberts@informix.com (Paul Roberts)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: conditional select sum() based on field question
  5. Keywords: select sum
  6. Message-ID: <1992Aug13.003128.8803@informix.com>
  7. Date: 13 Aug 92 00:31:28 GMT
  8. References: <297@praeda.UUCP.UUCP>
  9. Sender: news@informix.com (Usenet News)
  10. Organization: Informix Software, Inc.
  11. Lines: 73
  12.  
  13. In article <297@praeda.UUCP.UUCP> pete@praeda.UUCP.UUCP (Pete Frehner) writes:
  14. >
  15. >I have a question regarding selecting a sum from a table of amounts and
  16. >depending upon the type of record, either adding or subtracting the amount
  17. >from the sum.  We are using Informix 4.0 ISQL and R4GL.
  18. >
  19. >I could do this in two select statements and the difference would be the
  20. >net amount, but this requires that the data be read twice (once for each
  21. >select statment).  
  22. >
  23. >   select sum(amount) into total_credits
  24. >       from orders where order_type = "CREDIT"
  25. >
  26. >   select sum(amount) into total_normal_orders 
  27. >       from orders where order_type = "REG"
  28. >
  29. >   let net_amount = total_normal_orders - total_credits 
  30. >
  31. >
  32. >Is there a way that this could be done in one select statment??  Two select
  33. >statments is no big deal for a small database, but this database contains
  34. >hundreds of thousands of orders.  If the data could be read only once it would
  35. >pick up performance quite a bit.
  36. >
  37.  
  38. The way I would choose to do it is: store the amounts
  39. as negative numbers on "CREDIT" orders. i.e. treat
  40. the credit memo as an order which happens to be for a
  41. negative sum of money.
  42.  
  43. Then you can just sum() the lot and not worry about
  44. distinguishing the two types.
  45.  
  46. If this is not an option (e.g. because the system is
  47. already in place, and the dollar amounts on credit memos
  48. are positive, even though Paul Roberts thinks they should
  49. be negative), then there is this approach:
  50.  
  51. create a temp table called "fudge" and put exactly
  52. two rows into it, like so:
  53.  
  54. temp table fudge:
  55. -----------------
  56.  
  57.      char(6)       smallint 
  58.     order_type     f_factor
  59.     ----------     --------
  60.  
  61.       REG             1
  62.       CREDIT         -1
  63.  
  64. and then do this select:
  65.  
  66. select sum(orders.amount * fudge.f_factor)
  67.   from orders, fudge
  68.  where fudge.order_type = orders.order_type
  69.  
  70. The idea is that the f_factor will change the sign on
  71. the dollar amount to a negative value on the credit
  72. memos, just as the gods intended.
  73.  
  74. Whether this will help performance is another question
  75. though, since you do have to do the join (albeit to a
  76. very small table) and the arithmetic.
  77.  
  78. Might be worth a try though.
  79.  
  80. Paul
  81.  
  82. p.s. Tell your friends: qty_shipped and dollar_amount
  83.      should *both* be negative for credit memos! "price"
  84.      stays +ve, though. Have I suffered because I worked
  85.      on a system where this isn't the case? Yes, I have.
  86.