RE: Database programming standards
- From: "Goulet, Dick" <DGoulet@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 4 Jun 2004 09:19:20 -0400
Rob,
Where do you work?? Got any openings for a DBA??
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Rob Zijlstra [mailto:rmsah@xxxxxxxxx]
Sent: Friday, June 04, 2004 1:52 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Database programming standards
I'm a developer and I have no reasons at all to not keep business logic at
the db level. On the contrary! All the mentioned reasons for it at this
discussion I learned 'the hard way'.
But I might also add to the honorable DBA's here, that I learned a lot from
helpful dba's who took some time to explain some things... From the first
time on I visited this list, I saw that there are some people here, who in
my eyes are on such an Olympic level, that they cannot normally speak to us
lowly developers (or is that DUHvelopers??)
Furthermore I might add, that if you are a developer and do not know your
SQL good, do not use bind variables, then what in ..name are you doing in a
db environment?
Rob Zijlstra
================================================================
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Deen Dayal
Sent: Thursday, June 03, 2004 8:10 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Database programming standards
From what I gathered on this thread so far
I want to summarize with following
1) Java code should always use bind variables
2) Any open cursors/connection should be closed/released when the work is
finished and when no longer required
3) Keep the Business logic in the database using stored procs and packs
where ever possible to reduce network traffic and to ensure business rules
are always enforced.
I want to know from all of you out there: what are the reasons/arguments
developers have against #3
In other words are there any genuine practical reasons except what has been
mentioned by Mladen about making the app transparent of the RDBMS (which by
the way is a very good point, I will bring it up with my management)
Can any body add anything else to the list above?
The application we are about venture on is going to serve a lot of users, at
the peak close to 30K and there are going to be a lot of complex business
rules and my guess about the size of the DB should be around 500GB
Thanks to all for your help
Deen
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Daniel Fink
Sent: Friday, 4 June 2004 1:54 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Database programming standards
Gosh, this sounds like a rather heated discussion I had with an expert in
the past. His position was that the database was for storing data...only for
storing data. No RI, no check constraints, no stored procs, no triggers. His
argument was that anything related to business rules belonged in the
application layer.
Other bits stripped...
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
