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

[Ruslan Zasukhin]

on 5/23/03 9:53 PM, Andreas Grosam at agrosam at computerworks.ch wrote:

>> Hi Andreas,
>> 
>>> Here are my thoughts - although i did not address each of your ideas.
>>> [sorry please - i apologise for that huge mail ;)]
>>> 
>>> If I understood you right, firstly, your primary concern is to
>>> eliminate the overhead imposed by a SQL parser when processing queries
>>> specified in a string. IMO, the overhead will be not so significant -
>>> compared to a complex query requiring to access a disc.
>> 
>> Not a fact, Andreas.
>> 
>> One of Valentina C++ developers have point me that when he use BitSets
>> he
>> can get speed of query up to 100 times faster.
>> 
>> Parser really can take MANY time, Andreas.
>> Not only because of text. Also optimizer, planner.
>> With Bitsets developer __SOMETIMES__ can write VERY optimal plan.
> 
> OK, I see. Certainly, a full fledged SQL parser is a dreadful beast.
> 
> Besides this however - the API should be independent of the underlying
> implementation. I guess, a bitset is too implementation specific. What,
> if you sometimes change your Storage Manager using a different
> method/layout for storing the records making bitsets inappropriate?

I will think about this...but I do not think bitset will die.
This is the fastest structure.
Actually sometimes is used ArraySet.

So sometimes I think about general kind Result class.
I just do not see how then work with it.
Aha. No problems here. BitSet and ArraySet are bog inherited from Set.
Later Set can return Iterator. Just here start work virtual functions...

> As mentioned in the previous mail - in a relational DBMS the user / app
> developer gets access to the data by means of Relations only. The query
> should be declarative - even when using an API. Then the implementation
> chooses the best method to select the records.

Agree.
 
> You should assume, that an app developer or a user NEVER is able to
> choose the fastest method to get the records. Only an optimiser has
> enough knowledge how to choose the best plan. For instance it (the
> optimiser) knows: the analytical model - a formula modeling the
> hardware and certain components of the DBMS-  namely, disk latency,
> seek time, sequential read rate, size of buffer cache, buffer replace
> policy, read ahead policy, page utilisation, clustering factor,
> estimated number of records in the result set, access history, access
> method, etc., etc.

YES!!!

This is from where started discussion.
Developer just build a Tree of nodes that express his query.

This tree catch Optimiser, Planner.
Again, SQL parser build the same tree.


> What and how does a user choose this:  a full scan or a search by using
> the btree index?? How will he best partition the files in order to
> minimise page faults in the buffer cache? Will he mmap the file or is
> it better to read pages and extract single records per ordinary file
> IO? Are the columns of a table vertical decomposed?

> Well, managing all this and taking into account is the job of the query
> optimiser and the query executer. A user must not faced with it! You
> should attempt to achieve the same performance as the C++ developer
> mentioned above using the bitset. This sounds very difficult - but you
> need NOT to make the best optimiser ever in the first release- this is
> a part of a DBMS which can be improved over time.

It looks like you stay behind my back!  :-)
All correct Andreas.

> Consider, a Relation is a bitset is a cursors is a vector is a base
> file  - or what ever. This is totally opaque to the user - he should
> use a Relation for accessing records and nothing else. Then you have
> the greatest possible freedom of how to implement it.

Yes. Just we will name this fbl::I_Table

And I_Table interface later will be easy extended for inheritance,
As far as I see


-- 
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
-------------------------------------------------------------