Re: About grammar and syntax on a possible relational language
Date: Tue, 11 Mar 2008 09:42:54 -0700 (PDT)
Message-ID: <7b61a16d-eb4d-4264-9b4e-ce5f56a15a65_at_59g2000hsb.googlegroups.com>
On Mar 11, 4:55 am, Cimode <cim..._at_hotmail.com> wrote:
> (snip)
> SUMMARY
>
> By running the following at definition time
>
> [MAKE EMPLOYEE = {EMP# INT, LNAME CHAR, DOB DATE, SALARY INT}]
> [MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 100000]
> [MAKE VIP_MEMBER = {RICH_EMPLOYEE}]
>
> I am defining 3 relations differently and applying operators while
> establishing a de facto foreign key between VIP_MEMBER and
> RICH_EMPLOYEE as well as RICH_EMPLOYEE and EMPLOYEE. I use this de
> facto references to be able to write
>
> PRESENT2D [VIP_MEMBER WITH SALARY > 200000] --> 2 implicit JOINS.
>
> What do you guys think. I initially thought about using SET instead
> but I want to keep the idea of relation as a construct which is why I
> use the verb MAKE. I am hoping the above example wil draw some
> constructive comments..
>
> Regards...
Short comment/question on the syntax:
PRESENT2D - does the name imply that there will be other n-dimensional presentations available (PRESENT3D, e.g.)?
Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.
Regarding derived relation definitions, what would the expected behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to change after VIP_MEMBER was declared, e.g.: [MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000] My assumption is that the VIP_MEMBER relation would "dynamically" derive from the new definition. Is this correct?
TroyK Received on Tue Mar 11 2008 - 17:42:54 CET