| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.misc -> Re: Oracle object-oriented database objects - opinions
tk wrote:
> I must be lucky then as OO is actually being excercised rigerously at every
> position I have had the good fortune of being on (ie, extensive following of
> Gof design patterns as well as the Core J2EE patterns). I have had a
> chance to work with some very bright people (not including myself) and have
> been able to pick up on quite a few things.
That IMO is an exception.
>>Treating Oracle like it is merely a filing system deomonstrates IMO a >>serious lack of understanding about RDBMS (and Oracle specifically).
As I said TK, my comments were just general observations and not specifically aimed at you. So please - do not take my ravings personally. Besides, I'm always quick to foam at the mouth. :-)
Putting the business logic in the middle tier has all kinds of knock-on effects. Data now lives in two places. Instantiated objects in the middle tier. Rows in tables in the database.
Often the solution to this "problem" is to treat the database as a mere persistant object storage device. And as I said, you do not need Oracle for that.
> The tables and their relationship tables are
> normalized/indexed and constrained for the utmost performance. The
> relationships within the data models are quite normalized.
Which is as it should be.
> I fear there's a misunderstanding on what I said (perhaps on my part). The
> "data" model of the tables within the RDMS don't necessarily need to model
> the "business" object model.
I understand that. My take is that the business object model can be implemented inside Oracle.
> When a
> Business Object comes in and asks (for example) for billing statements and
> account information, the data may be gathered from various tables (to serve
> the purpose of normalization, etc...) that it never knows about. Maybe
> we're saying the same thing. We may have a middle tier method that calls a
> PL/SQL package to "get account information". That PL/SQL package may turn
> around and perform a bunch of joins from various entity tables (and
> relationship tables) to gather up all of the data in one nice ref cursor
> that the middle tier can "happily" read from.
Yes - providing a stored proc API to the developers. This has been common practise for almost a decade now in my experience.
> The middle tier can simply pass in array objects of data (or what have you)
> and the PL/SQL package(s) can multiplex them out across the various DB
> tables that make up the DB structure.
There's no reason why business logic cannot reside in PL/SQL too. It is a full blown programming language. Alternatiely using Java stored procs (though I cannot see the reason for that unless you're looking for features that PL/SQL does not provide like o/s command line access and stuff like that).
What business benefit is there to have the business logic layer totally separated from your database?
>>The word idiot comes to mind.
I was nor refering to that or you TK, but to the concept of treating Oracle as a "persistant object data storage system". One I had and still have to deal with - especially when dealing with the Java crowd.
>>Are you in that business TK?
A company's biggest IT investment made is in the back-end. Server hardware, o/s, and database. Getting the staff employed/trained to support that. Paying a lot for support & maintenance. Upgrades. Etc.
Along comes Mr Java Programmer and tells me that we need "database independancy". We must move the business logic into a Java 3-tier layer so that we can swap back-ends whenever we have the urge.
Telling me that "No, we don't need Oracle for that. We can put this into product X using Java on server Y". For dork's sake. Why on earth do we have a high performance feature rich database product?
Yeah.. as if we swap back-ends every 2nd Saturday. And thinking Oracle is just a glorified version of Microsoft Access.
So unless you're in the ISV business TK, developing off-the-shelve solutions for a market that runs on all kinds of databases and servers, that argument of 3-tier Java business layer just does not hold water in the real world.. at all.
>>Everyone is a "guru" these days. Few though have the hands-on >>experience to make their opinion something to take seriously.
> Well. The ones I was speaking of have 6-12 years of hands on Oracle and are
> Oracle 8 certified :-) One such gentleman has over 12 years hands on with
> it. I personally value their opinions very much so and am blown away with
> the Oracle knowledge that the 12+ year gentleman has (ie, guru DBA and
> PL/SQL programmer).
Ah.. in that case I will also take the opinions seriously. But I will still treat that as opinion. :-)
The only way I'm convinced is seeing The Thing working for myself. With the hood open.
> Don't get me wrong, so far I am liking PL/SQL and I can see a ton of cases
> to use it.
It is not an issue about PL/SQL. It is IMO a basic architectural one.
How will you handle MTS & AQ in a 3-tier? Why develop/pay for that when it already exist in Oracle. What about security? What about network bandwith (3-tier does mean 2x or even MORE traffic on the network)? What about complexity? What about ease of maintenance?
Can 3-tier beat the scalebility of hardware clustering and RAC? Or RAC and MPPs?
Show me real and tangible business benefits for 3-tier that cannot be achieved by using a 2-tier Oracle solution.
-- BillyReceived on Fri Aug 15 2003 - 16:24:08 CDT
 |
 |