Joe Weinstein
01-20-2004, 01:49 PM
References: <Y7IOb.20178$ko5.19870@nwrddc01.gnilink.net> <400C0C9E.40107@bea.com> <100qupghddk6cdf@corp.supernews.com> <JSfPb.2378$BA2.2152@newssvr26.news.prodigy.com>
In-Reply-To: <JSfPb.2378$BA2.2152@newssvr26.news.prodigy.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 216.148.48.12
X-Trace: news.beasys.com 1074635456 216.148.48.12 (20 Jan 2004 13:50:56 -0800)
Organization: BEA SYSTEMS Inc
Lines: 23
Path: intern1.nntp.aus1.giganews.com!internal1.nntp.ash.giganews.com!border2.nntp.ash.giganews.com!border1.nntp.ash.giganews.com!nntp.giganews.com!newshosting.com!news-xfer1.atl.newshosting.com!uunet!dca.uu.net!ash.uu.net!news.beasys.com!not-for-mail
Xref: intern1.nntp.aus1.giganews.com comp.database.oracle:16819 comp.databases.oracle.server:282726 comp.databases.oracle.tools:96117 comp.lang.java.databases:61461 comp.lang.java.programmer:688752
HK wrote:
Andrew Carruthers wrote: Logic should reside as close to the data as possible It looks like BEA documentation agrees with you: http://edocs.bea.com/wls/docs81/jdbc/performance.html#1025805 IMHO, you should code where you feel most comfortable. This does not mean doing data integrity checks in the middleware app. That should always be done in the DB.
I agree with you and the doc. (I wrote it ;-) ). That shouldn't conflict with
data caching, nor business rules/logic where the cache is. That documentation
refers to JDBC programming, to prevent row-by-row raw data retrieval to
clients in Java to do dumb iterative, non-set-based processing, like I described
in the payroll application that was converted to 4 pipelined stored procedures.
Joe
In-Reply-To: <JSfPb.2378$BA2.2152@newssvr26.news.prodigy.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 216.148.48.12
X-Trace: news.beasys.com 1074635456 216.148.48.12 (20 Jan 2004 13:50:56 -0800)
Organization: BEA SYSTEMS Inc
Lines: 23
Path: intern1.nntp.aus1.giganews.com!internal1.nntp.ash.giganews.com!border2.nntp.ash.giganews.com!border1.nntp.ash.giganews.com!nntp.giganews.com!newshosting.com!news-xfer1.atl.newshosting.com!uunet!dca.uu.net!ash.uu.net!news.beasys.com!not-for-mail
Xref: intern1.nntp.aus1.giganews.com comp.database.oracle:16819 comp.databases.oracle.server:282726 comp.databases.oracle.tools:96117 comp.lang.java.databases:61461 comp.lang.java.programmer:688752
HK wrote:
Andrew Carruthers wrote: Logic should reside as close to the data as possible It looks like BEA documentation agrees with you: http://edocs.bea.com/wls/docs81/jdbc/performance.html#1025805 IMHO, you should code where you feel most comfortable. This does not mean doing data integrity checks in the middleware app. That should always be done in the DB.
I agree with you and the doc. (I wrote it ;-) ). That shouldn't conflict with
data caching, nor business rules/logic where the cache is. That documentation
refers to JDBC programming, to prevent row-by-row raw data retrieval to
clients in Java to do dumb iterative, non-set-based processing, like I described
in the payroll application that was converted to 4 pipelined stored procedures.
Joe