Re: Scalars & atomic values & variables

From: Lauri Pietarinen <lauri.pietarinen_at_atbusiness.com>
Date: Mon, 05 Jan 2004 15:45:09 +0200
Message-ID: <3FF96A65.9010007_at_atbusiness.com>


Bob Badour wrote:

>"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message
>news:3FF904F7.3060207_at_atbusiness.com...
>
>
>>Dawn M. Wolthuis wrote:
>>
>>
>>
>>>Therefore, unless everyone is discussing the exact same set of objects
>>>(which could be defined by a set of types) and operators, the use of the
>>>term scalar is inexact and apt to be confusing as different values will
>>>
>>>
>be
>
>
>>>scalar in different models. When the whole idea of the model is to be
>>>extensible, then the term scalar is also not very useful as adding in
>>>another function/operator into the space and/or adding in new objects can
>>>change what is and is not a scalar.
>>>
>>>
>>>
>>If we think of scalars in terms of what can be seen by relational
>>
>>
>operators (union, projection, cartesian product, etc...) it would seem
>
>
>>to me that defining scalars as values that cannot be "cracked open" with
>>
>>
>these operators would pretty well do it for me.
>
>That strikes me as entirely arbitrary. One can crack open a string using an
>operation that returns a relation of position/character tuples. I guess that
>makes a string non-scalar.
>
Well, I don't know what the definition of a relational operation is, but if we decide that such a function
is not a relational operator then it is not arbitrary.

Anyway, we can always change our database upside down by simply creating a view using (scalar) functions, e.g.

create view vperson1 as
select
 substr(person_name,1,1) as pn_1,
 substr(person_name,2,1) as pn_2,
etc...
from person

...or...

create table table_num ( n integer primary key ); insert into table_num values(1);
.
.
insert into table_num values(9999);

create view vperson2 as
select
  person_id,
  n
  substr(person_name,n,1) as person_name_char from person, table_num
where table_num.n <= lenght(person_name);

But the key distinction is that we needed the help of operators that can "understand" and operate on scalar values.

Relational operators that are derived from the original "UNION", "JOIN", "PROJECT" (... or what have you ...) do not belong to this group.

regards,
Lauri Pietarinen Received on Mon Jan 05 2004 - 14:45:09 CET

Original text of this message