How do I obtain detailed View Info

Question

II am working with someone who is trying to develop a procedure capable of creating "Instead of" triggers against any view that is passed in as a parameter. Such a procedure could reduce development time, as the "Instead of" trigger creation of the more complex views are somewhat time consuming. We plan to use updatable views more in the future as they seem to greatly simplify the interface on web development projects, between the database and the application developers.
Unfortunately, we seem to have encountered a limitation in being able to do this in an automated way, which according to the developer is insurmountable.
The challenge is that we are unable to consistently and reasonably determine the hierarchy of the tables within a view. For example, to populate the foreign key column in children tables, the primary key of the parent table must first either be created (i.e., in the case of an insert in the parent table), or selected if the parent record existed previously. The developer has tried two different approaches to resolving this problem, and has stated that neither were successful. The approaches already tried were:
1) Running an explain plan against the view, and then retrieving the table hierarchies from the explain plan tables. His remark about this solution was:
"Explain plain doesn't show hierarchy of table joins."
2) Attemping to derive the hierarchy from the Foreign Key Constraints of tables being used in the view. His remark about this solution was:
"It works but only for simple joins. When there are several references to same table "where" clause should be parsed to find out what field references some table instance which is not trivial."
Apparentlty when we join to the same table multiple times within the view (i.e., getting both a persons home phone and their cellphone from the PHONES table), it somehow complicates the matter.
Is anyone aware of a method of reliably getting table hierarchy information from a view, so that we can accomplish our goal? The only other idea which someone suggested was to temporarliy create a "Materialized View" of the view, and then retrieve the table hierarchy from the "Materialized View" tables. He will attempt that approach shortly.
Ay thoughts or suggestions would be greatly appreciated!

Answer 1

While updateable views and instead of triggers do have their place, I'm not convinced that that place is to "... greatly simplify the interface on web development projects, between the database and the application developers". Personally, I think that is why Larry invented packages.
It seems to me that what you are trying to do is something like:
CREATE VIEW everything_there_is_to_know_about_an_employee AS
SELECT every_column
FROM every_table_sometimes_two_or_three_times
WHERE all_possible_joinsThen use instead of triggers on that single view to do all operations.
It seems to me that a package based API would be much cleaner, easier for developers to use, more maintainable, more extensible, and more scalable. I would seriously consider creating a package along the lines of:
CREATE PACKAGE employees AS
   FUNCTION get_demographics(p_empid IN NUMBER) RETURN SYS_REFCURSOR;
   FUNCTION get_job_history(p_empid IN NUMBER,
                            p_enddt IN DATE DEFAULT sysdate) RETURN SYS_REFCURSOR;
   FUNCTION get_sal_history(p_empid IN NUMBER,
                            p_enddt IN DATE DEFAULT sysdate) RETURN SYS_REFCURSOR;
   PROCEDURE hire_employee (p_frname IN VARCHAR2,
                            p_srname IN VARCHAR2
                            p_empid OUT NUMBER);
   PROCEDURE transfer_employee (p_empid IN NUMBER,
                                p_tojob IN NUMBER,
                                p_effdt IN DATE DEFAULT SYSDATE);
END;If you want to pass the "objects" form your web service instead, that is relatively easy to do. You could create objects in the database like:
CREATE TYPE emp_job_tp AS OBJECT (
   empid   NUMBER,
   empname VARCHAR2(50),
   jobid   NUMBER,
   jobname VARCHAR2(50),
   eff_dt  DATE);
CREATE TYPE emp_job_tbl AS TABLE OF emp_job_tpand pass those into and out of the stored procedures.
JPublisher, a component of Jdeveloper, can automatically build the classes and methods to transform java objects to SQL Objects and vise versa. So, you get a set of re-usable methods on the app side that can be used for other applications, as well as a set on the database side.
Sure, somebody needs to write the packages, but a fair bit of that (particulalry the single table APIs) could be automated just as easily as the instead of triggers on simple views.
One of the in-house applications I work on gets interfaces from several of our applications dealing with patient demographics, visits, orders and results. For a variety of reasons, the incoming messages do not necessarily come in strict time order, so a typical setter procedure has a signature something like:
PROCEDURE set_medication (p_med  IN Medication_tp,
                          p_pat  IN Patient_tp,
                          p_vis  IN Visit_Tp,
                          p_auth IN VARCHAR2,
                          p_fac  IN VARCHAR2);The java message parser creates objects (in the java sense) from the message for the medication order, the patient demographics and the visit information. Using the Jpub created classes, these are converted to the defined Oracle types, and then passed to the procedure. The procedure, not the java app, determines whether the patient already exists or not and takes appropriate action (insert, update or nothing), similarly, it determines whether the visit exists and whether the medication order exists, and takes appropriate action.
On the other side, there are web services calling multiple getter procedures and serving those to one of several dozen user facing applications. In general, the getter procedures return either an object (e.g. a patient object), a table of objects, or a refcursor, depending on the expected volume of data. Some of these getters are specific to one of the user facing applications, others are used my most, if not all, of them.
Not an updateable view or instead of trigger in the lot, although I do use both in other applications.
Just my 0.02 $CDN.
John