Re: About grammar and syntax on a possible relational language

From: TroyK <cs_troyk_at_juno.com>
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

Original text of this message