""zifnabbe"" <zifnabbe@...> wrote in message
news:a3eamg+s9f1@......

>
> > I'm still curious about why you need to use views for these...what
> is your client application environment?
>
> Hmm, I thought to use views instead of queries in my application
> environment (delphi) to speed it up...
> Or am I wrong on this?

Views are logical, virtual tables. They are SELECT commands encapsulated in
a callable name. They can hide the complexity of a JOIN or UNION. They can
restrict user input only to the WHERE conditions that's defined in the view.
You can give columns a new name (title) for output other than the names they
had in the base tables. A view's trigger is the only trigger that can change
the semantics of the underlying tables (you can convert an insertion in a
view into an update in the base tables). Beware that triggers on views using
UNION don't work reliably for now.
Views do not have space to hold data. If you want this, get Oracle and
define a so-called and proprietary "solid view". <g>

You can read the binary instructions that define the view operations with a
command like this in isql, the command-line utility:

SQL> set blob 2;
SQL> select rdb$view_blr from rdb$relations where rdb$relation_name = 'V';

Procedures were meant to optimize access. Typical example is a batch
operation that is to be done on thousand records in a table and needs only a
few parameters. Getting each row in the client, modifying it and sending
back to the engine is waste of time and bandwith. Just create a proc, pass
it the required parameters and execute it.

IB and FB allow for selectable stored procedures. They can produce result
sets much more complex than a view, where procedural steps should be taken.
But again, you only have pre-defined commands, not data.

Procedures and views serve another need: the need to kill redundancy.
Instead of updating all clients applications that do the same bunch of
operations, you put those statements on a procedure (or a view, if it's a
complex SELECT) and call the procedure/view from your application. A single
point to change.

You should read LangRef. It's an interesting doco for anyone. It defines
most of the functionality available in the engine. Otherwise, you will be
always asking basic doubts.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing