Re: ER/Win vs Designer/2000 - Which is better?

David Ng wrote:
>
> Jim Russell wrote:
> >
> > Robert Miller wrote:
> > > From what I've seen of Erwin's Oracle schema generator, I was not
> > > impressed. Perhaps it was due to cockpit trouble on the part of the
> > > designer. (sorry, modeler...)
> > >
> > > Instead of generating declarative referential integrity constraints when
> > > foreign keys are specified, the thing create a trigger for every foreign
> > > key.
> >
> > I've seen that same output from ER/Win, and I wonder if I'm just failing
> > to understand it -- the thing generated bunches of triggers rather than
> > defining constraints. I also played once with S/Designer and was
> > underwhelmed -- When I tried to reverse engineer a DB I had set up by
> > hand, the damn thing ignored existing trigger definitions, and replaced
> > the constraints defined with a slew of triggers. Can someone explain
> > the reasoning behind that??
> > (With ER/Win, my target db's were SQL Anywhere and Oracle 7; in
> > S/Designer I was using just Oracle 7.)
> > --
> > /Jim Russell (temp alt: russelj0_at_hoffman.army.mil)
> > Entity: an object with no class that doesn't know how to behave.
>
> I consider that is one of major strength of ERWin. ERwin can generate
> same triggers for different target databases. Further, it can generate
> some triggers that is not easy to program in the target database. For
> example, to ensure casecade update between master and detail table in
> Oracle database, it take a quite a lot of effort to do so. ERWin can
> generate trigger for that on the fly and save you a lot of effort.
>
> David Ng

David,

First, you do not need triggers for on delete cascade. Declaritive referential integrity specifies this when the table is created. The statement is ON DELETE CASCADE. No trigger required.

This is not a strength but a pox. Declaritive referential integrity is the industry proven way to go. I'm probably wrong, but I always thought it was part of ANSI92 entry level. (I hope Joe Celko isn't reading this). TRIGGERS ARE SLOW (at least they were at the time I saw product displayed). In Oracle, they started life as interpretive. In 7.3 they are now compiled. Also databases have a limit (usually or initially) that can be applied to any one table. I suspect this technique is there for one reason. This "feature" is the least common demoninator a CASE tool generator can use and CLAIM it supports another vendors RDBMS.

I was appalled, and I would not allow purporting to build a database like this for me or my customer. This same modeler, might then claim "Oracle is Slow" when the application is placed into service. Received on Wed Apr 09 1997 - 00:00:00 CEST