"Filip Rembiałkowski" <[EMAIL PROTECTED]> writes:
> hmmm. just a general notice:
>
> A customer loyalty program, which expires earned points, not to let
> the customer "win" anything valuable?
> If I were your client, I wouldn't be happy with this.
On the other hand, having the possibility is bet
hmmm. just a general notice:
A customer loyalty program, which expires earned points, not to let
the customer "win" anything valuable?
If I were your client, I wouldn't be happy with this.
2007/3/18, Naz Gassiep <[EMAIL PROTECTED]>:
We are running a customer loyalty program whereby customers
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Naz Gassiep
>Sent: zondag 18 maart 2007 14:45
>To: Naz Gassiep
>Cc: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] Design / Implementation problem
>
>Here it is again
Naz
First, there is nothing you can do about the computational load except make
your code as efficient as possible. Get it right and then make it fast.
But there is only so much you can do. If a "calculation" requires an
integer sum and an integer difference, you inevitably have two integer
Naz Gassiep <[EMAIL PROTECTED]> writes:
> that calculating the point
> balance on the fly is not an unfeasibly heavy duty calculation to be done at
> every page view?
One alternative to calculate it everytime is calculating it once a day. If
there are calculations for today, then just read the c
Here it is again with more sensible wrapping:
*** The Scenario ***
We are running a customer loyalty program whereby customers earn points
for purchasing products. Each product has a value of points that are
earned by purchasing it, and a value of points required to redeem it.
In order to prev
This is possibly not a DB only problem, the solution may involve
application logic as well. But PG users
are the smartest bunch I know. Ass kissing aside, here are the details:
*** The Scenario ***
We are running a customer loyalty program whereby customers earn points
for purchasing products.
