RE: SQL/ordering data based on a computed result/stored procedure?

[rob@xxxxxxxxx]

Whose says you can't store it in the database?  Just don't store it
physically - use a view.

Rob Berendt

==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "jt" <jt@ee.net>
                    Sent by:                  To:     <midrange-l@midrange.com>
                    midrange-l-admin@mi       cc:
                    drange.com                Fax to:
                                              Subject:     RE: SQL/ordering 
data based on a computed result/stored
                                               procedure?
                    11/13/2001 08:57 AM
                    Please respond to
                    midrange-l






Reeve,

I may be old-fashioned, but I've held to the idea that if you have a need
to
sort on a computed field, you should have that in the DB.  I would suggest
triggers to implement the business rules, although there is a performance
hit.

JMHO.

jt

> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Reeve Fritchman
> Sent: Tuesday, November 13, 2001 8:12 AM
> To: Midrange-L@Midrange. Com
> Subject: SQL/ordering data based on a computed result/stored procedure?
>
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> I need to display data in ascending order where the key field (price) is
> dynamically computed.  I can do this with the QLGSORT API's and I
> can do it
> with funky RPG; I'm wondering if I can do it with SQL and stored
> procedures,
> or something of that ilk.
>
> "Price" is a function of the item's base price and the current incentives
> (discounts) in place for that customer/product line combination;
> the actual
> incentive is determined from a complex set of business rules.
> Therefore, a
> $100 item with a 20% discount (net $80) becomes less expensive than a $90
> item with a 10% discount (net price $81), and I'd like the $80
> item to show
> up before the $81 item.
>
> So, SQL reads a group of items, applies a function to the item base
price,
> gets a "net" price, and presents ordered-by-net-price data into my
> application program.  It seems simple enough?
>
> No green-screen, client/server, or CFINT opinions are required!
>
> Thanks,
> rf
>
>
> --
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.