🚀 go-pugleaf

Isaac wrote:

> I wonder if I can use computed by to sum all detail records or is it
> only limited to the current table ?.

I do not understand what you mean by "computed by".

> 
> ex
> select sum(f) from table where f2 = value

That will work.

-- 
Bill Todd (TeamB)

in the create table field definition "computed by" can I use the select 
statement ?

CREATE TABLE table [EXTERNAL [FILE] 'filespec']
(col_def [, col_def | tconstraint �]);
col_def = col {datatype | COMPUTED [BY] (expr) | domain}
[DEFAULT {literal | NULL | USER}]
[NOT NULL]
[col_constraint]
[COLLATE collation]
.
.
.
.
.

P.S: How newsgroup support bold or italics ?

Isaac wrote:
> CREATE TABLE table [EXTERNAL [FILE] 'filespec']
> (col_def [, col_def | tconstraint …]);
> col_def = col {datatype | COMPUTED [BY] (expr) | domain}
> [DEFAULT {literal | NULL | USER}]
> [NOT NULL]
> [col_constraint]
> [COLLATE collation]
> .
> .
> .
> .
> .
> 
> P.S: How newsgroup support bold or italics ?

_bold_ or /italics/?

-- 
Will R
PMC Consulting

willr wrote:
> Isaac wrote:
>> CREATE TABLE table [EXTERNAL [FILE] 'filespec']
>> (col_def [, col_def | tconstraint …]);
>> col_def = col {datatype | COMPUTED [BY] (expr) | domain}
>> [DEFAULT {literal | NULL | USER}]
>> [NOT NULL]
>> [col_constraint]
>> [COLLATE collation]
>> .
>> .
>> .
>> .
>> .
>>
>> P.S: How newsgroup support bold or italics ?
> 
> _bold_ or /italics/?
> 

or maybe *bold* i dunno

-- 
Will R
PMC Consulting

Isaac wrote:

> in the create table field definition "computed by" can I use the
> select statement ?

Yes, you can use a computed field in a SELECT statement.

-- 
Bill Todd (TeamB)

Bill Todd [TeamB] wrote:
> Isaac wrote:
> 
>> in the create table field definition "computed by" can I use the
>> select statement ?
> 
> Yes, you can use a computed field in a SELECT statement.
> 
sorry I was not quit clear I want the contrary I want to use select 
sum() to return the computed by value

*Thanks*

_*Thanks*_

Isaac wrote:

> sorry I was not quit clear I want the contrary I want to use select
> sum() to return the computed by value

I do not recall if that  will work or not but it is a very bad idea.
The SELECT SUM will run _every_ time the record is accessed whether you
need the sume or not. This is likely to cause poor performance.

-- 
Bill Todd (TeamB)

Bill Todd [TeamB] wrote:
> Isaac wrote:
> 
>> sorry I was not quit clear I want the contrary I want to use select
>> sum() to return the computed by value
> 
> I do not recall if that  will work or not but it is a very bad idea.
> The SELECT SUM will run _every_ time the record is accessed whether you
> need the sume or not. This is likely to cause poor performance.
> 
ok speaking of performance Mr Maxim tell me a good way to get two sum 
values with for select ...

for
   select field_a, sum(field_b)
   from t
   group by field_a
   into :v_a, :v_sum_b
do begin
   if (v_a) = 1 then some_var_1 = v_sum_b;
   else if (v_a) = 2 then some_var_2 = v_sum_b;
   /* and more if's if ther are more distinct values in field_a */
end


is this better in performance (for a stored procedure) than using 2 Selects

ex:

select sum(f) from tab1 where f2 = 1

Thanks
select sum(f) from tab1 where f2 = 0

Isaac wrote:

> is this better in performance (for a stored procedure) than using 2
> Selects

It should be because you only have to scan the data once.

-- 
Bill Todd (TeamB)

Ok thanks alot

Hi.

You can but it will be very inefficeint.

It's better to create triggers on detail table and update regular (not
computed) fields in the master. De-normalisation though...

Calculated fields will be better only if you have very strange read/write
ratio (in favour of write) for a usage senario of your database.


Maxim.

"Isaac" <no@no.com> ???????/???????? ? ???????? ?????????:
news:483c6824@newsgroups.borland.com...
> Hello,
> I wonder if I can use computed by to sum all detail records or is it
> only limited to the current table ?.
>
> ex
> select sum(f) from table where f2 = value
>
> Thanks

Maxim Shiryaev wrote:
> Hi.
> 
> You can but it will be very inefficeint.
> 
> It's better to create triggers on detail table and update regular (not
> computed) fields in the master. De-normalisation though...
> 
> Calculated fields will be better only if you have very strange read/write
> ratio (in favour of write) for a usage senario of your database.
> 
> 
> Maxim.

ok thanks alot