Best approach for performing DMLs using stored procedures

Question

Hi,
I have a really general question and would like to hear your say about this.
I want my application to manipulate or read data using stored procedures (or packages in that manner) and not directly using queries against the DB.
Let's say I have a table with many columns:
create table test (pkid number(10),col1 varchar2(30), col2 number(10), col3 date,...);For such a DML procedure, is it best to do something like
procedure do_update(i_pkid IN number,i_col1 IN varchar2, i_col2 IN number, i_col3 IN date,...) as
begin
   update test
   set col1=i_col1,
        col2=i_col2,
        col3=i_col3...
   where pkid=i_pkid;
   commit;
end;Or do a selective update, meaning update only a certain column every time, given only 1 column actually changes? (and how to do that - separate procedures for each column? [columns can be nulls])
Also, is it better to work with test.col1%type instead of specifying the data type in the procedure?
And one last question - If I have a table with 100 columns and I don't want to create a procedure with 100 parameters - the best approach would be to use a record?
I just need to be set on the way I start implementing things in order to do it well from the start.
Many thanks.
Edited by: Pyrocks on Nov 17, 2010 1:58 PM

Answer 1

Pyrocks wrote:
One last clarification (although it may be more related to c/c++ developers - maybe one of you will know):
We are working with C++ and VB against a SQLServer and my part is to translate all the existing procedures to Oracle in order to migrate the application to work with Oracle DB.
The existing procedures use an IN parameter for each column in the table and I would really like to use rowtype like you mentioned.
Since I'm not a c/c++/vb developer - is there an easy way of working with such types, or even User-Defined Types, from c/c++/vb (as in passing a rowtype record from c++ to a SP ?)
I'm not looking for the actual way - just want to know how hard it would be and how much code needs to be changed in order to be able to convince the developers that this is the RIGHT way to work.
PS. none of our developers have experience with ORACLE so they wouldn't know the answer...Not actually an Oracle server-side (SQL language or PL/SQL language) question - but a client one. And it has been a long time since I wrote a fat client using C/C++ or Delphi.
The OCI (<i>Oracle Call Interface</i>) supports advance (user defined) SQL data types. Has since Oracle 8i. So in that respect, yes the client can support custom SQL data types.
How well it does depends entirely on that client language's features wrt OCI integration. For example, Delphi 4 was release around Oracle 8i and supported custom SQL types. I would expect that most languages today (like Java and C#) will provide support for it.
As for usiong +%ROWTYPE+ - this is a PL/SQL clause as far as I know. Unsure whether it is supported by the OCI. What could support it is a pre-compiler like Pro*C. These enable you to mix pseudo SQL source code with client language source code. The pre-compilation step then replaces the pseudo SQL code with native client language calls to the OCI. The code is then compiled by that client language's compiler. Pre-compilers can pull all kinds of interesting "tricks" with their pseudo SQL code support.
The best would be to consult the applicable client language's manuals that describe the interface it supports (via OCI) to Oracle.