OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [Fwd: RIM 0.54 and RS 0.83 distribution]




--
Regards,
Farrukh



Mike,

A related point that your conversation has brought up is that we need a
section in the RS spec "Constraints on subset SQL syntax", which describes
in bullet form constraints that cannot be expressed syntactically in the BNF
but need to be enforced in the semantic analysis phase of the processor. I
would appreciate specific suggestions you may have.

Michael Rowley wrote:

> Farrukh,
>
> I was reading your query BNF and had some questions.
>
> Are you sure you want the "IN" clause, with arbitrary nesting of
> subqueries?  I think this would be especially hard to implement
> efficiently with anything other than a relational databse.
>
> In general, it looks like your subset would allow queries that I think
> would be difficult to implement if you stored your data in XML, or any
> form other than in a relational database:
>
> For example, the following queries for all unique combinations of the
> values from the x and y columns of table 'a', and the z column of table
> 'b'.
>
> SELECT DISTINCT a.x, a.y, b.z FROM a, b
>
> Here is one that would do a 3-way join:
>
> SELECT FROM a, b, c WHERE
>    a.x = b.x and b.y = c.y and a.z = c.z
>
> Of course, nested subqueries could be used to create some hairy requests
> as well.
>
> In one of your recent email's, you said that you implemented the query
> processor for this BNF in 4 hours, but mentioned that you hadn't bound
> it to your back end yet.  It seems like you have primarily just done
> parsing then, which is usually easy, so it doesn't surprise me that
> it would only take a few hours.
>
> One of the main arguments made after the invention of SQL was that you
> can create a language which appears to be asking for very run-time
> expensive behavior (joins, cross-products, etc), but that with a
> sophisticated query optimizer, it should be possible to actually execute
> the query in a reasonable amount of time.  I would hate to require that
> people either use a relational database, or implement their own query
> optimizer.  It is hard to write a query optimizer.  That is one of the
> main reasons that JDO chose a filtering-based query feature, which does
> not open the possibility of arbitrary joins and cross-product creation.
>
> Michael

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard


begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC