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
|