My $0.02: If you really want to try OR (not truly OO as in Object-Oriented,
but Object-Relational) features of Oracle, look at object views. These were
meant as a way to migrate from relational to object-relational model, but
appeared to be more useful as replacement for native o-r support in Oracle.
You keep relational data model and you create a set of object views over it
allowing you to explore this same data in object-relational way, without
all that overhead Oracle adds for managing o-r data storage and relations.
Data can be easily manipulated both ways and yet it is still pretty manageable
since it is stored in classic relational way, where Oracle excels.
--
Vladimir Zakharychev (bob@dpsp-yes.com) http://www.dpsp-yes.com
Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications.
All opinions are mine and do not necessarily go in line with those of my employer.
"Sherlock" <sherlock_at_mailmetoday.com> wrote in message
news:4d1a3c52.0208282040.15662a82_at_posting.google.com...
> Oracle Version: Oracle 9i
> Development platform : JSP and Java
>
> For those of you unfamiliar with mechanical engineering parlance
> Castings, Forgings are different ways to make a product using a metal.
> In castings molten metal is pured into a mold wheras in forging heated
> metal is shaped.
>
> Let me describe my requirement. I have different Supplier tables , one
> for Casting Suppliers , one for Plastic suppliers, one for Forging
> suppliers etc.
> All these supplier tables have several columns in common
> (street,city,zip, country so so....).
> Example:PLASTIC_SUPPLIER table will have ID(Primary key), Name,
> Address, Street blah blah....
>
> **Each** of these supplier models have some other things in common.
> For example, i have a table for the Machining facilities for Plastic
> suppliers, a table for Machining facilities for Casting suppliers
> Example:CASTING_MACHINE table will have Lathe, Grinding, Milling as
> individal rows. Similiarly PLASTIC_MACHINE may have a different set of
> rows.
>
> Of course, for each of these i have an association table implementing
> the many-many relationship. i.e it will tell me which plastic supplier
> has which machine
> Example: PLASTIC_SUPPLIERMACHINE table will have the ID from
> PLASTIC_SUPPLIER and the ID from PLASTIC_MACHINE
>
> Like PLASTIC_MACHINE and PLASTIC_SUPPLIERMACHINE i have **half a dozen
> tables*** for plastics. Similiar for Casting, Forging etc. For example
> i may have PLASTIC_FACILITIES, PLASTIC_CERTIFICATIONS anologous to
> PLASTIC_MACHINE
>
> The database approach followed earlier was the simple Relational
> model. Easy to understand/Easy to use. No problems at all.
>
> Lately, i was starting to get some bright idea about using Oracle's
> Object oriented features. After some poring over manuals, i made some
> observations on which i seek your opinion
>
> **I am studying in a university. My project is a prototype and not to
> be used commmercially. Moving to an OO model will cause some student
> who sees this database structure throw his head in despair. it would
> take any student atleast one month to completely understand the
> intricacies of OO databases. Syntax is convoluted and makes one wonder
> what the fuss about OO is about.
> In Java, one can visualize immediately the tremendous benefit of OO.
>
> **The benefits that come by using this model/moving to this model seem
> to be questionable. Even simple SELECT/INSERT statements change. This
> will mean that all JSP pages will have to be recoded. Querying Nested
> tables/defining VARRAY's
> is not simple to understand for a new comer or even someone relatively
> experinced in programming. No more select * from mytable !
>
> **Remember reading some SQL Guru (Celko?) saying that he had to "clean
> up" some OO database and convert it back to relational form since it
> had become unmanageable.
>
> However, I am very open however to your valuable opinions. Can someone
> give your opinion why or why i should not move to the OO Model?.
>
> Karthik
Received on Thu Aug 29 2002 - 08:52:02 CDT
