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

[Suros, Juan]

Ruslan,


Here's an example of how this problem is solved in an existing system. In ABAP (script language of SAP R/3) there exists a standardized structure called SELECT-OPTIONS.

field		type
-----------	----------------
SIGN		char(1)
OPTION	char(2)
LOW		data dictionary dependant
HIGH		data dictionary dependant

SIGN:	can be {I,E} to Include or Exclude a range
OPTION: can be {EQ,NE,GT,GE,LT,LE,BT} which are equivalent to (=,!=,>,>=,<,<=,BETWEEN)
LOW: low value of range (or single value)
HIGH: high value of range

To use this functionality, I create a range object nd fill it with a query:

RANGES: range_t1 FOR table1.

range_t1-SIGN1 = 'I'.
range_t1-
range_t1-


-----Original Message-----
From: Ruslan Zasukhin [mailto:sunshine at public.kherson.ua]
Sent: Friday, May 16, 2003 7:52 AM
To: valentina at lists.macserve.net
Subject: [ALL] let's think about Query Language for 2.0


Hi Guys,

I write now specifications for feature of Valentina 2.0 -- Query.

This is my comments from C++ code.
Do not be afraid this is plain text for now :-)

Read this text and find TASK after it.


> 1) Query is the BRAIN of database kernel.
> 
> 2) Query allow us execute search and sort on Tables without SQL.
> We can consider this as low level engine of query execution.
> SQL is bult over this as higher level. It will use something from Query    and
> add own algorithms.
> 
> 3) Query must be able to support Relational model, Netowrk model,
> Object-Relational model and Object model.
> 
> 4) Query can be one of the next kinds:
> 4.1 Single Column.
> For example,     f1 = 5, f1 > 5, f2 LIKE 'asd', f2 REGEX '.*22'
> RESULT is Set of records of Table
> 
> 4.2 Single Table.
> For example,     (f1 = 5 OR f1 = 15)
> (f1 >=5 AND f1 <= 7)
> f1 BETWEEN 5 AND 7
> RESULT is Set of records of Table
> 
> 
> 4.3 Multi Table ???
> Query cannot be of multi-table kind, because this require usage of LINK
> apart.
> RESULT should be something complex as JOIN Table.
> 
> 5) In the 4.2 point, query can be of any complexity. We must be able analyse
> it,
> build the optimal plan of execution, execute. If needed explain the plan.
> 
> 6) We must be able describe Query in terms of c++ and other langauges, using
> simply API.
> We will not use for this STRINGs like in SQL, because this require parser.
> We will use something like factories to step by step build tree of query.
> 
> 7) The query is represented by Tree of ENodes.
> 
> 8) When we get the Tree of ENodes we start Query.Execute().
> During it we ask Planner to build Tree of Plan_Nodes.
> Then start execute this plan.
> If tables was not changed, this plan still is up to date and can be used for
> repeated search if need. So plan is stored in the Query object.
> If tables was changed, then we will need build plan again.
> 
> 9) Query can work as on indexed so not indexed fields.
> Planner take this into account of course.
> Depending on combination of indexed and not indexed field, and on operations
> itself,
> we can get 
> a) column searches that return BitSets, then combine that bitsets.
> b) scanning of table and filtering of records.
> c) at first SET searches, then scanning for selection we have got before.

So guys, the dream is to make in 2.0 the "SQL parser+engine" as separate
plguin for Valentina itself.

Developer should be able, if he want, do work without SQL at all.
This can be for many simple dbs, or for network navigational model,
Or just to be faster to avoid SQL overhead....

This feature will require new classes in Valentina for RB and other
products. It will bring life to V4RB BaseObject class, which confuse some
people why it exists today. I have told, problem is that V4RB have not
SEARCH classes that have c++ SDK.

So let's think now about this search classes API.
I expect that the most active will be V4RB developers, although this feature
can be added for ALL APIs.

Open your mind, and let's dream together.

Assume you work with Table Person.
What classes/functions you need to describe simple single table query?

    Query = NodeEqual( Person.fldName, "Bill" )
    Query.AndNode( NodeEqual( Person.LastName, "Gates") )
    QueryResult = Query.Execute()

Something like this.
This is the same as SQL query:
    
     str = "SELECT * FROM Person
            WHERE Name = 'Bill' AND LastName = 'Gates'"
     cursor = db.SqlSelect( str )

As you see API can be comparable to SQL way by lines of code.
Actually SQL can be even longer if think about varaibles and concatenations
to build string of query.

And API way should work faster, because no conversion of numeric values to
sting, no SQL parser which should do huge job. Simple tasks should be
resolved by simple things.


Try to invent a great API together with me.
Okay?


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