Miscellaneous

ID#

Question

Answer

1

Are Oracle U classes any good (in general)?

These courses are as good as the instructor.  If your instructor is 3 slides ahead of the class, you might as well stay home and read a book. Find out who is teaching ANY course you are about to take and look at their resume.

In general, Oracle courses are well written and thoughtfully prepared. They do not tend to give you much help with product weaknesses and workarounds. Frequently, the courses seem a little marketing biased. A good instructor will give you a good class and gloss over the less useful parts of the class notes, going into depth on the things that are really important.

I have been to great Oracle classes and ones that the entire 5 days could have been delivered in 1.5 days. The relevant variable is NOT the class, it is the instructor.  Oracle U has great instructors as well as kids that should be taking the class rather than teaching it. The trick is avoiding the latter.

We usually all overlook that the most expensive part of a course is the time you are spending away from doing work.  A week out of the life of a basic developer is about $2000 (with overhead).

2

A) What are Oracle's future plans regarding Developer/Designer products?

B) What is the correct advice for the project manager?

Oracle’s answer from Sue Harper Designer Product Management Oracle Application Development Tools:

BC4J Generation from Designer

Recently there has been some discussion on this list about generating Java from Designer, and the potential for integrating with JDeveloper. Hopefully the following will not only address some of these issues but also give you a heads up as to one part of Oracle's Application Development Tools strategy.

 Oracle9i Designer and Forms are both mature and stable products. Oracle will continue to invest development effort in both Designer and Forms to ensure that they maintain their rich levels of functionality and current market position.

 Oracle9i JDeveloper introduces UML modeling and Java generation to the tool base. A part of that functionality includes the ability to model Entity Objects, a fundamental structure in the Business Components For Java (BC4J) framework. We expect to be extending this functionality in the future to support the modeling and generation of all the BC4J components, and more.

As you know, Designer has rich schema and program module meta-models from which you can generate complete applications. These meta-models share semantic similarities with the BC4J model, and our intention is to develop generator technology to create BC4J components from Designer schema and module elements in the Oracle9iDS Release 2 timeframe. This generator will be invokable from both Designer and JDeveloper. The model is therefore 'push' and 'pull'; a one-way trip from Designer to JDeveloper.

***********************************************************************

Paul’s answer:

Developer is not dead, Designer is not dead.  Oracle is not going to pull the plug as long as any of us are likely to care.  Developer and Designer will continued to be supported and enhanced well into the future.

Yes, it looks like Oracle is putting more intellectual resources into JDev, but it is still a relatively immature product.  There is no data modeling to replace the powerhouse of Designer other than some basic UML support. Standard client server application development in JDev is much less efficient than Developer with a good template.

Much of Oracle Applications are still based on Developer. They will not shoot themselves in the leg.

Designer, after some early resistance is now making noises about some JDev integration (BC4J support maybe a JDev generator someday).

Developer continues to evolve and there are plans for enhancements.

That said, it looks dire for the "long" run lifetime of Designer and Developer. Some of the big Designer thinkers (Ian Fisher, Dai Clegg) are working on the repository or JDev. At the panels on the future of development, JDev is talked about, Designer and Developer are not.

I suspect that we will get incremental improvements in both Designer and Developer but we will not get the big rewrites that both products need. That intellectual growth will happen in the JDev space.

Also, I do not see the Oracle world rushing to adopt JDev. As long as many stubborn, old timers still build in Designer and Developer, the products will not die.

We are in a state of flux.  Web development is still maturing.  We would like to move to JDev for core internal application development, but Developer is way better for the things that Developer can do.

The best advice is to build your applications thin.  Use generic data models and lean towards a business rule based approach so that most of your rules do not live in your applications but instead live in a repository or at least in views and stored procedures.  Count on the fact that your next rewrite will quite possibly be to an application development product that you have not seen yet.  Or at least a version that is significantly different from what you now have

P.S. I hereby curse the next person that asks if Designer and Developer are dead to be locked in a room and forced to program in COBOL and RPG for a month.

Oracle's position statement can be found at:

http://otn.oracle.com/products/designer/htdocs/ModelingStrategyJuly02.htm

3

Yuga Chodagam asked:

 I happened to open this magazine which has Cache's advertisement that said "EYE OPENER - FOR ORACLE USERS". What Cache is trying to address (in their marketing materials anyway) is the "impedance mismatch" between OO business components and relational databases.  It really got me thinking. Is there a better way to store the data for reporting purposes? Star schemas address some issues but then there are other types of requirements. Our users want to see lot of counts and percentage increase/decrease etc. for which we are having to write whole lot of PL/SQL code and create a lot of tables and store the data and retrieve them on demand. And we create many views and functions to get the data the way we want. So I was hoping to see some new technology that provides a solution for these reporting requirements.

I think the "impedance mismatch" is quite real, both for OO as well as data warehouse.

However, I don't think we need a new DBMS engine to solve the problem. What we need is to have tools that think in terms of dual levels of generation, namely:

1) Generate the relational tables, but also...

2) Generate the structures that we need and want as developers (views or whatever)

To some extent, the "impedance mismatch" even exists between relational databases and entity relationship diagrams. If we want to generate the "right" DB from our logical models, we either had to bastardize our entity relationship models or make separate physical database models that were difficult to keep in synch.  So we avoided using all sorts of things in Oracle Designer such as:

1) Multi-column primary keys with dependent (UID bar) relationships

2) N-level deep supertype, subtypes

3) Many-to-many relationships

Designer never was able to give us all sorts of things that would be useful such as derived attributes and complex validation business rules enforcement just because you couldn't stuff them into a table.

I think we happened upon the right idea when we were doing projects that eventually resulted in our BRIM^® engine.  The idea is to generate both the tables and views simultaneously.  That way, you can generate nice relational tables that follow normalization rules but you can also generate views and potentially other redundant structures to provide the UI for developers.

The "impedance mismatch" in Object-Orientated (OO) databases only results because people keep trying to generate a class diagram to tables. Direct mapping to tables only works if you rip out half the great things that OO does. If you generate views (or ADF BC, or EJBs) that look exactly like your class structure but also generate relationally "clean" tables, then you get both a good database as well as a good fit for the OO world.

I think the same approach can be taken with data warehousing.  You probably do not need a new kind of engine. My experience resolving the OO "impedance mismatch" leads me to believe that the Oracle engine is MUCH more robust than you think.  What we are missing is a way to bridge the "impedance mismatch."

My suggestion is to try to imagine what the "right" tool is for warehouse design. Then, either build it yourself and approach a vendor to help realize your vision. If you have any nice thoughts about how it would work, maybe we can enhance BRIM^® to support you.  BRIM^® already includes the infrastructure to handle 2 layers of generation.

Kamal Mutneja asked: Please explain a little bit about mutating tables/triggers

and the simplest solution to this problem

Mutating tables is not an internal bug in Oracle.  It is the engine trying to prevent us from doing something potentially stupid.

Mutating tables are caused by a trying to query the same table that you are triggering (on most triggers).  In general, this is a logically unsafe thing, so the engine prevents it.

There are several workarounds that people have used over the years:

1) Early on, mirrored tables were perhaps the most popular solution. An entire copy of the table was maintained and then the trigger could query the mirror table.

2) Views can have triggers that can do anything you want so you will never get a mutating table error, but neither will they prevent you from doing something really stupid.

3) Autonomous transactions can be used for some mutating table problems, but not all of them

In general, the idea is to be very careful before you employ such strategies.  You are getting the mutating error for a very good reason. Make sure you understand that the solution you come up with will not be problematic later on.

4

Marcus Bacon of Creative Design Associates asked:

Toon Koopelaars' article in the latest ODTUG Tech Journal is very detailed and well thought out and makes a lot of sense.  My bias shows.  I have always felt that a database centric Model (Model-View-Controller design pattern for J2EE (MVC)) would be the best approach.

There is one thing I am curious about.  Is this approach more efficient and has anyone compared performance between the 8 different approaches of thin and fat tiers as described in the paper or at least the most common ones? 

The ultimate question is how do we evangelize the Java heads to this approach?  Better still, how do we convince management that this is the best approach?  I think the keys are performance and productivity.  Where should code go?

Toon Koopelaars' article in the ODTUG journal suggests a thick database approach to web development.  It seems to contradict conventional wisdom about placing code in the middle tier. 

I don't know if I can say we have done a formal study of the performance improvements, but I can attest that Toon is bang-on in his suggestions.  We tried to buy into the fat middle-tier approach when we first tried to build BRIM.  Our tree refreshes took minutes!

We re-architected the BRIM repository manager 4 times as it evolved, and each time we moved more and more into the database. 

At the same time we have been building J2EE web systems in our consulting practice.  The most telling example was a project we inherited that was built by "skilled Java developers".  The performance was TERRIBLE. There were places where we were able to take routines and improve the performance by more than 10 times, just by moving the code down to the database (where it belonged).

The Java-heads will fight you. But the only logical argument you will get

is: "it makes us database-independent".  The other big argument is: "all my friends think so". Unless I am making a product to sell to all database environments, I don't much care about database independence.

It is a pretty clear argument on the database side. If the routine is going to have lots of round trips to the database, it will run faster if it actually is IN the database.

We have evolved a formal methodology in our systems where we do EVERYTHING we possibly can in the database.  We build dedicated views for each and every screen, encapsulating all logic in instead of triggers on the views.  

We even place all application logic in a database repository so all that is in the applications are calls to the repository.  We call it "ultra-thin" client development.

As we are in a world where the development environment is volatile, the only real defense is to put as little as possible in anything but the database.  That way we can move to the next cool thing when it comes along with a minimum of pain. The web development world is so painful right now that the only thing you can be sure of is that it will keep evolving for the next few years.

5

Kevin Durant asked: I am currently working on a paper for school "The Relationship between Development Methodology and Success on Large IS Projects" and I Just read your paper on the Top 10 Reason why systems projects fail. In your paper you mention a sound methodology is required but also state no empirical research has been done to indicate one method over the other.

I have two questions that I would like to have addressed from your perspective:

(1) Which methodology is widely accepted that works?

(2) Which is more important: project management skills or the method chosen?

Paul replied:

Largely, I am not much of a believer in one method over another.  Any one seems to work as well as any other.  At the end of the day, the method is:

1) Figure out what the system needs to do

2) Do it.

Whether you organize requirements by use cases, functional hierarchy, or place things in big cardboard boxes, it all seems to break down to the above.

I do think that rapid iterative delivery is "good" (see my presentations on Extreme Business Rules for details), but other than that, I think it is more important that you use SOME method rather than a SPECIFIC method.

Management skills are MUCH more important than method.  It is all about keeping track of what needs to be done and making sure that it gets done.  Think of it like a pathfinder.  You are on a journey.  You climb up to the top of a hill to see where you are, then you look way off in the distance to see the ultimate goal, then you plan your day's journey to make sure it gets you closer to the final goal.  Then you climb down and walk for a day.  Then next day, you repeat the process.

The failure of projects is often due to the fact that we are too busy to stop and climb up the tree or to plan where we are heading and how we will get there.  We think that we can just keep walking and eventually stumble on the final destination.

I know that this sounds like silly common sense, but you would be shocked at how often multi-100 million dollar project failures can be described in exactly this way.  

6

Henry R. Miller asked:

Should Oracle store logical constraints in the database?

Paul replied:

I had a discussion about this with Ken Jacobs of Oracle Corporation a few years ago. I was trying to get him to add basic things that I was thinking about (that eventually made it into BRIM^Ò) as part of the DBMS.  I wanted him to provide display columns, multi-lingual support, etc. right in the DBMS. He indicated that I should be talking to the Oracle Applications team.

At the time I was frustrated by his reluctance to think about this kind of stuff.  But as the years went by, I have to come to believe that he was 100% right.  The DBMS provides tables, views, indexes, etc.  It is NOT the place for logical constraints.  It provides a way to implement a logical vision.  The logical structure can and should remain independent.

My rules motto that we use at Dulcian is: "The articulation of the rules is independent of the implementation of the rules." The idea is that the system is really several things:

1) the rules

2) the algorithm to generate

3) the physical choices (indexes, etc.)

4) the generated system

5) hand coding and post generation stuff

One could integrate the rules into the DBMS, but then what happens when the architecture stack changes?  On a recent project, we took a major BRIM^Ò system running on Oracle using Forms and converted it to Java and .Net running on SQL Server.  The independence of the rules made that possible.

There are some places where Oracle is integrating rules into the DBMS. They are working on an ECA tool where the rules are embedded in the DBMS.  As a result, I think it is a useless product that will never fly. No matter how good the product is, this is fundamentally the wrong idea.  The DBMS should be about implementation.  The tool should be about articulation.

This separation of rules and implementation is the essence of the rules approach.  Even the rules vendors by-and-large don't get this.  In most products, the rules ARE the implementation of the rules.  

7

Ashok Chand asked:

Does anyone know the difference between Oracle 10g and MS SQL Server 2005?

Paul replied:

We did not do a point by point comparison but we did recently work on a project where we had to convert the BRIM^Ò mapper (an ETL tool) to SQL server. This was not an easy transition for a number of reasons:

1)       SQL Server does not have sequences. You can only get auto-generated columns when you insert, so there is no easy way to perform an insert with master detail records. There is no industry standard workaround.

2)       You can only have 8000 characters in a SQL server record. This is a big problem because you cannot use varchar2(4000), and everything with large text columns has to be done with the SQL Server equivalent of CLOB.

3)       There is no CONNECT BY in SQL Server SQL, so recursive structures are a difficult to handle. Since there is no industry standard workaround, no one uses recursion (not even Microsoft in the design of the MS project repository.

4)       IIS cannot run Java.

5)       I am pretty sure they didn't have INSTEAD OF trigger views, but that might have been recently (or is about to be) added.

Those were the biggest problems.   It is so much nicer to work with a real DBMS.