|Subject||Re: [IB-Architect] Trigger Templates|
>lol, here we go again, the old, capability/ease of use/readability vs.Exactly. I remember when I first heard about late-binding implementations of
object-oriented languages (like Delphi!), I thought it was terribly
>my vote's for the first, on a system that's not speed dependant. (ie a fewmine to. But, I would say that in the end, Speed is not just run-time speed.
>milliseconds = lotsa dollars).
It is also development time, debugging time,...
>Excuse me for being a show stopper, but is this another solution lookingIt is not like we have to have this today. But it is always good to have a
>for a problem?
vision towards what we should do tomorrow.
Point being: the newer Analysis tools, e.g, UML, (and even languages) have
gone object oriented. But basically, with IB we are still stuck with the old
>As I see the problem, it's that currently, repetitive code should beIf we choose to say at this level, (I mean the relational non-object
>retyped. Tools like Erwin allow for code templates to be applied quickly,
>without any change on the engine.
oriented), we might find that IB would be to database what COBOL is to
But also, this object oriented capability does not need to be implemented in
the engine (BLR/Kernel) level. It could happen somewhere above that. IB has
arrays. Arrays are a way to implement Object-Oriented features. So, it could
happen in the translation level. (Like C++ -> preprocessor --> C -->
compiled code). The change is at the language level.
For example, if I need to place insert/update timestamps in all my tables,
and I have 200 tables, I would need to make -- and maintain -- 400 triggers.
But with trigger template capability, I can do it with 400 things only (one
trigger template for insert, one trigger template for update, and
instantiating statement to implement insert trigger templates on the tables,
and another for updates.)
Going object-oriented also gives us a better opportunity fot repositories
and reuse. blah. blah..
Lastly, other database servers are going object-oriented to eliminate the
impedance between object-oriented analysis (like UML) and database
implementations like IB. (Oracle already has object-oriented features).