[ALL] let's think about Query Language for 2.0

[Andreas Grosam]

On Freitag, Mai 23, 2003, at 09:11  Uhr, Ruslan Zasukhin wrote:

> on 5/23/03 1:52 PM, Andreas Grosam at agrosam at computerworks.ch wrote:
>
>> A more C++ like example:
>>
>> This shows some code examples which reside in the client side (as
>> interfaces and libraries).
>>
>> - Note that this is just an idea! (However, several parts have already
>> been implemented and proofed to work in a
>> previous framework)
>> - Note that this example is in C++ and uses templates, which may be 
>> not
>> available in all languages,
>> but can be bypassed or it can be implemented in a slightly modified 
>> way.
>>
>>
>> // Suppose these classes have been defined in namespace db elsewhere:
>> class db::Relation;
>> class db::Tuple;
>> class db::TupleDescriptor;
>> calss db::ColumnDescriptor;
>> class db::Predicate;
>> class db::equal_pred;
>> class db::less_than_pred;
>>
>>
>>
>>
>> // Create a "tuple descriptor". It describes a tuple(mainly attributes
>> and types). Can be re-used.
>> // A tuple descriptor is a list of column descriptors.
>> // In this case, a tuple descriptor will be created which has two
>> column descriptors,
>> // one which is labeled "FirstName" and is of type string, the other 
>> is
>> labeled
>> // "DOB" (means, "day of birth") and is of type date:
>> TupleDescriptor td;
>> td.push_back(ColumnDescriptor("FirstName", make_type_desc<string>()));
>> td.push_back(ColumnDescriptor("DOB", make_type_desc<date>()"));
>>
>> // Note that a column descriptor may have several properties - which
>> are not shown here.
>>
>> // Create a relation with a specified tuple descriptor and attach it
>> the base table "Persons".
>> // Note that this may throw an exception if the tuple descriptor is 
>> not
>> applicable.
>> Relation persons(td);         // c-tor with explicit row-descriptor
>> persons.open("Persons");      // may throw "descriptor_does_not_match"
>
> Okay Andreas,
>
> Now I see that your term Relation is analog of "virtual table -- VIEW" 
> in
> Standard SQL. Correct?
>
Not exactly. A relation is something more abstract - its internal 
implementations is totally opaque. This is especially important!
Well, a Relation has rows (records, tuples) and columns (attributes). 
You can get a reference to a row (record, tuple) - but otherwise for a 
client it is totally unimportant how it stores its rows.
In fact, a relation may directly reference a base table residing in the 
server database, or a temporary table, or a temporary table residing in 
memory in the server  side or in the client side, or it may even be 
created by a client using a std::vector as internal container for its 
records.

> Please look on next syntax then:
>
>     I_Table* pPersons; // pointer on Persons Table.
>     I_Table* pMySubTable = pPersons->MakeView( "FirstName", "DOB" );
>
Here, you just apply the projection operator with its arguments 
"FirstName" and "DOB" on the base table "Persons". You get another 
Relation pMySubTable.
That is, MakeView() is a member function performing a projection 
operator. Assuming MakeView() is a const function, it can be expressed 
in formal relational algebra (not working example, just for 
illustrating!!):

I_Table* I_Table::MakeView(list of names)
{
    Relation r = projection(*this, "list of names");
		//get a new relation from *this having only two cols

     I_Table* tmp = new Relation(r); // create a copy if r on the heap

    return tmp;
}


> I think this syntax is more short and readable.
> Table pPersons already know type of fields FirstName and DOB.
>
This is a "higher level" function.

> Okay, you will say that your syntax allow apply tuple descriptor to any
> table that have fields with name "FirstName" and DOB.
> Then we can modify syntax:
>
>     I_Table* pMySubTable = MakeView( "FirstName", "DOB ");
>     pMySubTable->OpenOn( pPersons );
>
> Or even more short:
>
>     I_Table* pMySubTable = MakeView( pPersons, "FirstName", "DOB ");
>
> I think in 99% cases developer what in view the same types as in 
> original
> table.

In fact, there is little difference. This is a matter of inventing 
higher level functions.

My attempt was to show the "formalism". How it would actually work on a 
low level. There are only a few classes.

Note: the TupleDescriptor is already existent in form of an 
implementation. I will send you the source, soon. (Its not on this 
machine where i am writing this mail currently). So you can take a look 
on it.


Andreas

>
>
> -- 
> Best regards,
> Ruslan Zasukhin      [ I feel the need...the need for speed ]
> -------------------------------------------------------------
> e-mail: ruslan at paradigmasoft.com
> web: http://www.paradigmasoft.com
>
> To subscribe to the Valentina mail list go to:
> http://lists.macserve.net/mailman/listinfo/valentina
> -------------------------------------------------------------
>
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina
>