Re: How to populate column changes system-wide?

On Sat, 01 Sep 2001 21:41:13 +0800, Dino Hsu <dino1.nospam_at_ms1.hinet.net> wrote:

<x-posting deleted>

>>type of column) called 'product number', say 7-digit in length, which
>>might well exists in hundreds of tables (forms, reports as well), and
>>we want to change it to 10-digit later, it is as easy as to change a

The change is easy using the object layer in ORACLE. Actually, just a change in length doesn't even require that. However, I think the "populate" (if I understood correctly what you mean by this) would be a problem.

>>
>>I have spent hours reading the Application Guide - Object Relational
>>Features, I have found nothing related to my underlined question, just
>>explanations about objects, types, methods, attributes, references,
>>collections, etc.. Can you give more specific information?

Define a type for your modifiable-base-type(s), then use the defined type in all your tables.

I think you'll still have problems as there is no easy way that I know of to "alter" a type. You can replace or create it, but not alter.

Someone else might have another view on doing this? Literally.

>>
>>An object model is usually meant to hold the business logic (thus
>>objects) and stand as the middle tier between application client and
>>database server, however, it takes more time to plan a 3-tier
>>architecture (object-oriented or object-based) than 2-tier
>>(relational), I wonder how many businesses have done this.

Some of the big ones like SAP and Peoplesoft have, AFAIK. With various degrees of success.

>As to the
>>object model provided by Oracle, I also wonder how many of Oracle
>>users directly utilize it in their applications,

Whenever I can. But not all the way through. I don't think it's been "flushed out" sufficiently for extended use. So where I can do it without seeing major problems coming up, I use it. Found it particularly helpful when dealing with J2EE-stuff using JSP and Beans. It provides a level of isolation between the Java code and the database storage which I find quit useful.

It's not easy to make changes to JSPs once things are under way. In particular, database design changes after a JSP has been written cause all sorts of problems. In this environment, I go for broke in abstracting the database design from the application code. Using views, objects, packages, beans, etc. I just don't want hard coded SQL inside the JSP (best way of ensuring you'll never be able to change a single thing in the DB...).

>>
>>By the way, I remember in a Data Warehousing/Mining seminar, the
>>concept of 'data administrator' (not 'database administrator') is
>>defined. A data administrator is, unlike a DBA, not preferrably a
>>technical person, and is responble for modling the business meta-data.
>>The reason is simple, the meta-data is meant to be shared and
>>understood by all departments, not by IT alone. Again, I wonder how
>>many businesses have done this.

Mixed feelings. I can understand the concept and its need, but I can't see it being implemented successfully with current rdbms engines, regardless of maker.

Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam Received on Sat Sep 01 2001 - 20:44:09 CDT