[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OODB query interface



 
I think the algebra functions and where clauses work well as a filtering system when objects datatypes are similar to that of a RDBMS, that is numerical and alphanumerical values. However, complex datatypes in objects require at times more sophisticated form of query. For example a vector model or a 3D polygon model in form of a object has little use of the operators mentioned.
 
Therefore, it requires that queries directly related on the schema, as such, one object in the schema might be identified by header based field or datatype while another might have a method built in to have a unique access to the complex datatype directly and perform unique queries related specifically to the nature of the object.
 
It is therefore my view that all queries on the OODBMS be generated from the schema, and all functions and operators of a programming language such as Java be available as a resource to be performed to each object based on the needs of its application. As such I suggest that we can call this API initiative Query By Schema(QBS). This requires that the Database freely publish its schema or a portion of it as a snapshot at any time. In preference this should be implemented in a GUI interface format.
 
While SQL might be referred to as a 4GL. I see it as similar to another CO type programming language. In trying to replicate SQL that is then 10 years old is reverting to ancient and old technology. I think the power of simplicity and graphic front ends, such as a birds eye view of a database structure and its contents ( or any of its  it segments), is what I will call today's state of the art.
 
always
schneur 
----- Original Message -----
From: Ola Berg
Sent: Sunday, August 06, 2000 3:07 PM
Subject: Re: OODB query interface

>It should be dynamic and ad hoc while delivering responses from the query in both the OOdbms  >basic data along with procedures used to manipulate the data for its proper use (methods).
 
I agree in most parts, but I am not sure if the natural language approach is the right thing. Object-dot-notation is both precise, OO-friendly, and not too difficult to understand for a non-programmer.
 
For the most part, the database systems will be queried by programmers. If non-programmers queries them, they demand graphical user interfaces (which wasn't common when SQL was invented) anyway.
 
>While these function might reside and operate on top of an API. The API should be viewed as the >backbone for the feature listed above.
 
Therefore, I suggest that the prime query language is the language of the API in an object oriented fashion, and that different graphical and natural language interfaces are implemented on top of that.
 
But let's skip the skin and dive into the gore: what types of operation does it need to support?
 
I have come up with three kinds, two of which operates on sets (or bags) of objects, and one that operates on objects:
 
1) Normal set algebra on objects (joins etc)
 
2) Filtering, that is selecting subsets of objects that meet certain criteria (like WHERE clauses)
 
3) Following references.
 
/O