Dear all,

Consider the following situation:
I have a table "T" that holds only simple data. I also have a bunch of
storedProc that takes table T's primary key as an argument and return
some processed value (could be anything from a single integer to a
varchar(50)).

To simplify things, I'm thinking of writing a view like this:
...
CREATE VIEW V (
pk,
data1,
data2,
data3,
data4,
...
dataN
) as
select
T.pk,
(select data1 from spGetData1(T.pk)),
(select data2 from spGetData2(T.pk)),
(select data3 from spGetData3(T.pk)),
...
(select dataN from spGetDataN(T.pk))
)
from T;
...

I was going to implement data1,data2,etc as a COMPUTED FIELD, but I
changed my mind since some of the calculations in the storedprocs can be
time consuming. As far as I understand it, using a computed field will
incur a penalty on every access to the record.

My questions:
1. In order to show the full data from T, the View V must be joined to
the Table T again.
...
select T.*, V.*
from T join V on (T.pk = V.pk);
...
Can anyone advise me on the performance implications on such
constructs?
2. If the join is 'slow', then getting rid of the join means that I had
to include ALL of T's columns inside the VIEW. Is this preferable than
the above construct? Again, performance is my biggest concern here.
3. Just in case I'm doing this all wrong (again..:), please advise on
how to propery design the database objects in my situation.

Thanks in advance,
sugi.