I gave up on getting a single SQL to do this; I don't think it's possible?

Question

Guys
I asked a little while ago about a loyalty points system where the loyalties could not be revoked once awarded, so any refunds would make the points system "go into debt" internally and only start issuing loyalty points when the debt was cleared. Got an excellent SQL to do just that, and then they switched requirements on me.
Now, loyalty points can be revoked at any time. It might be that on the 10th Sept a refund transaction dated in MARCH will be inserted that effectively wipes some loyalty points off the balance.. So I'm thinking that I have to mark transactions with a date of when they were used to create (or revoke) points
I'm wondering if someone will sense check my logic and confirm that there isnt a way to do this with read-only SQLs:
An UPDATE query runs, looking for transactions that have not already participated in the points scheme (points_date is null), and meet certain criteria, and setting their points_date to the current trunc(sysdate) -- this ensures that a transaction inserted in retrospect (i.e. inserted long after the date the transaction occurred) will have an effect on points
An hour later a select query runs on all transactions that have a points_date that is not null, grouping up by the card number (cards earn points) and the value of all transactions is summed. Transactions are classed according to their points_date; those that have a points_date before today contribute to the previous_total_spend and all transactions contribute to the current_total_spend. Because there is 1 point for every $10 spent, the amounts are divided by 10, and then FLOORed/CEILed to provide a quantized representation of the number of points a card had yesterday and what is has today. The delta of the number of points from previous to current represents the number of points that should be awarded or revoked.
I have to sum all transactions for all time rather than just do a simplistic "divide every tran by 10 then floor and thats the number of points" because customers who always spent 9.99 wouldnt accumulate any points ever when the should be entitled to one point upon their second purchase (taking their spend to 19.98)
Here's an example code for you to play with; can someone check I've got this right/the maths is robust and if there was a way to do this in a one-step SELECT without the update (I don't see how retrospective transactions could be included properly) let me know?
with t as(
select '20090301' as points_date, 15 as tran_amt, '1234' as card_num from dual
union all
select '20090302' as points_date, 11 as tran_amt, '1234' as card_num from dual
union all
select '20090303' as points_date, 15 as tran_amt, '1234' as card_num from dual
union all
select '20090304' as points_date, 42 as tran_amt, '1234' as card_num from dual
union all
select '20090305' as points_date, 84 as tran_amt, '1234' as card_num from dual
union all
select '20090306' as points_date, -14 as tran_amt, '1234' as card_num from dual
union all
select '20090307' as points_date, 10 as tran_amt, '1234' as card_num from dual
SELECT
  card_num,
  spend_today,
  spend_before,
  spend_today/10 as points_today,
  spend_before/10 as points_before,
  CASE
    WHEN spend_today < 0 THEN
      CEIL(spend_today/10)
    ELSE
      FLOOR(spend_today/10)
  END as quantized_points_today,
  CASE
    WHEN spend_before < 0 THEN
      CEIL(spend_before/10)
    ELSE
      FLOOR(spend_before/10)
  END as quantized_points_before,
  CASE
    WHEN spend_today < 0 THEN
      CEIL(spend_today/10)
    ELSE
      FLOOR(spend_today/10)
  END -
  CASE
    WHEN spend_before < 0 THEN
      CEIL(spend_before/10)
    ELSE
      FLOOR(spend_before/10)
  END as quantized_points_delta
FROM
    SELECT
      card_num,
      SUM(TO_NUMBER(tran_amt)) as spend_today,
      SUM(CASE WHEN points_date < '20090307'--TO_CHAR(sysdate, 'YYYYMMDD')
            THEN TO_NUMBER(tran_amt) ELSE 0 END) as spend_before
    FROM
      t
    WHERE
      points_date IS NOT NULL and
      points_date <= '20090307'--TO_CHAR(sysdate, 'YYYYMMDD')
    GROUP BY
      card_num
  ) totsBy changing the hard coded dates (will be based on report run date when live) you can simulate days passing..
Thanks in advance for any wisdoms

Answer 1

Well I'm leaning the other way. I think my present MBP will be the last Apple product I buy.
With the way Apple is going, all New Mac computers are sealed unit that don't allow the user to upgrade them in any way. They are getting more expensive initially. They are impossible to fix, even by Apple. All the parts are either soldered to the Logic Board or glued inside the case parts. The add on warranty only covers manufacturing defects and is expensive. And to fix one out of waranty is close to if not more then a new system.
The only thing different in a Mac, and most other products Apple sells, is the operating system and the cases they come in. As for the OS both have their glitches and at this time there are no viruses that infect OS X. There is more software available for Windows. More choices as to what hardware you can use or upgrade to at a later date.
Mac computers are becoming large iPads or iPhones with built in keyboards.
jeremy_from_rome wrote:
And as for the question: PC or Mac, the consensus that I hear from colleagues and friends is just as you state it: stay with Mac, be patient, work at it, and you’ll never look back! Thanks again