[Fwd: RIM 0.54 and RS 0.83 distribution]

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

--
Regards,
Farrukh

---

• From: Farrukh Najmi <najmi@east.sun.com>
• To: Michael Rowley <mrowley@exceloncorp.com>
• Date: Thu, 18 Jan 2001 10:37:41 -0500

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