Re: Object table - Changes to object question confirmation

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1089161998.167504_at_yasure>...
> Luch wrote:
>
> > Did some research (and tried it myself) and this is what I understand from
> > object tables (or tables that have one if its fields being an object type)
> > in 9i.... In order to make a change later on to the object, any table that
> > is using it (wheter it is one field or an object table) would first have to
> > be dropped. Otherwise it gives dependency errors. Is this correct? This
> > doesn't make sense to me... How can it be expected that an object can never
> > later be changed (adding another field, increasing a varchar2 field, etc).
> > This makes them "useless" to me to want to use an object in a table.
> >
> > -
> > Replace nospam with hotmail for e-mail.
>
> I think correct but your assumption about it being useless is incorrect.
>
> You are supposed to data model your schema then code. If you hava some
> overwhelming need to redefine objects on-the-fly it only demonstrates
> a lack of putting together proper specifications before you started
> banging out code.
>
> Daniel Morgan

Also, data types are more "fundamental" than table designs. You should not think of object data types as an alternative to relational database design, but rather as fundamental building blocks on which columns will be based. You should no more need to redefine your object data tyes later on than you should need to redefine the DATE datatype.

Unfortunately, this point is not generally understood, and so people define types called things like EMPLOYEE_TYPE and DEPARTMENT_TYPE, full of attributes like SALARY, JOB, etc. Of course these are unlikely to remain stable for ever, and so are NOT sensible candidates for object data types. Received on Wed Jul 07 2004 - 04:12:12 CDT