| Subject | Re: [IB-Architect] Select procedures |
|---|---|
| Author | Greg Deatz |
| Post date | 2000-06-08T17:30:44Z |
Personally....
you would do for a "parameterized-view", I'm particularly fond of the ability
to use a stored procedure to push and pull data simultaneously, and that I can
"softly" compensate for bad optimizer plans--in other words, I don't have to
explicitly say "plan", I can just write the proc as a series of
*well-"planned"* queries.
Of course, views, just like SPs, hide the mechanics of the underlying database
which is nice, but getting rid of "select-procedures", in my mind, would be a
terrible thing. Am I wrong? Aside from pure elegance, are there compelling
reasons to leave select-procedures behind?
> >At 10:32 AM 08-06-00 -0400, you wrote:I really *like* the select form of the IB stored proc. While I'm not sure what
> >
> >
> >>The design (not the concept) of the select form of the InterBase
> >>stored procedures is, in my ever humble opinion, is complete crock.
> >>It is, in fact, a computational form of a view and should have been
> >>implemented under the aegis of the view mechanism. With named arguments
> >>and appearing in rdb$relations, rdb$fields, and rdb$relation_fields
> >>(and the respective ODBC/JDBC meta data calls) it would have been
> >>easier to use, easier to implement, and much easier to wrap with
> >>intelligent code.
> >>
you would do for a "parameterized-view", I'm particularly fond of the ability
to use a stored procedure to push and pull data simultaneously, and that I can
"softly" compensate for bad optimizer plans--in other words, I don't have to
explicitly say "plan", I can just write the proc as a series of
*well-"planned"* queries.
Of course, views, just like SPs, hide the mechanics of the underlying database
which is nice, but getting rid of "select-procedures", in my mind, would be a
terrible thing. Am I wrong? Aside from pure elegance, are there compelling
reasons to leave select-procedures behind?