Eric Prud'hommeaux wrote:
* Arnold Daniels <[EMAIL PROTECTED]> [2007-09-08 18:11-0400]
Hi Eric,
== API stuff ==
I'm not fully agreeing with you here.
You can't strongly disagree with me 'cause i don't have a strong
opinion. I have a vague preference for the approach I've taken, and
will defend it 'till I'm dead^h^hbored. Seriously, I appreciate
this discussion.
Aren't you even considering, I might just convince you ;).
I think changing the API
just has to big of an impact on all the different clients. Let's
say you're use ODBC or PDO in PHP. There's no way to implement
that neatly. I really don't like automatic selection either cause
it's to easy to mess up.
My uninformed guess is that PHP, DBI, et al are using mysql_query. The
deployment challenge in that case is to add a call for the new API
entry, mysql_send_query, which is like mysql_query but takes an extra
parameter. Likewise, ODBC's executeQuery function would need to link
to mysql_send_query and have some settable var to indicate the
language code to use.
The point here was not about the examples. But there are a few mysql
clients out there: ODBC, /J, native PHP, etc. On top of those there
are hundreds of other drivers, usually multiple for each programming
language. All of these would need to be changed to support parser
switching. Now on top of those there are thousand and thousands of
DB abstraction classes and libs. All of those would need to be
changed as well.
Besides that, the API off all of these clients can't break
compatibility. In many cases that means that having a second
parameter to choose the parser is out of the question. Adding a
function like you did for the mysql client isn't a possibility for
most clients either, since they are data access abstraction layers,
having to conform to a specific API. Sure in most cases you can come
up with a workaround. But it will be a huge mess.
If you don't like to integrate the parser, perhaps a good solution
is to select it with a local setting, so you could do:
SET LOCAL query_parser=PARSER_SPASQL;
SELECT ?s WHERE { ?s <foo.bar> "hibbyhop" };
The problem with that is getting back. SET (LOCAL|GLOBAL) is parsed
SQL parser. Each parser would have to implement its own way of getting
back or you'd lose the flexibility of being able to intersperse
queries.
Each parser would need to implement the SET command, I don't see a
problem there. Implementing a specific command `PARSER SPASQL`,
could also work. Though not to add yet another non ANSI keyword,
something like `SET PARSER SPASQL` would be a better alternative.
That way you don't need to implement SET in each parser. Though I
think having set in each parser would be a good idea, since is it
the way to control how MySQL acts and you want to be able to do that
no matter what type of query your sending.
== XQuery stuff ==
I don't see the use of just mapping the relational data to XQuery
like you did in the example (and how do you see a join in that?).
XQuery is useful if you have XML as a string in a column. If you
need it in XML form going back and forth from XML to relational
data can be a drag. But if you want to use relational data most of
the time, switching to a pure XMLDB isn't an option either. Hence
the DB2 solution.
Generally, the appeal of querying relational data as XQuery is less
appealing to the SQL-heads than the XQuery-heads. The XQuery vision,
like the SPARQL vision, is that there is a unified data model that all
data is projected into. At that point, you can do queries that join
data in HTML documents, spreadsheets, databases, tea leaves and goat
entrails (still in the research phase).
That could be nice, but it doesn't exist yet. I'm not to interested
in standards in research phase, because it will take years and years
before we will see something a standard. Currently XQuery is used to
query XML. It uses doc() to select the source, though MySQL doesn't
work with document based storage engines, they work with tables,
columns and rows. However in a cell there might be XML data,
therefore integrating XQuery in SQL is far more logical.
I think the preference for XQuery as the outside language stems mostly
from the use of URIs as global identifiers (while MySQL allows you to
specify a database in any field spec, it's not a global identifier).
However, I'm not hoping to convince folks here to switch to XQuery or
SPARQL, just that there are people who want to query MySQL data that
way.
In this scenario what exactly would be the advantage of adding
XQuery to MySQL. I could just use Berkeley DB XML if I want to
exclusively choose for XQuery.
I guess you could imagine each row to be a node and do
doc(mytable)[/acolumn/text()='banana']/mycolumn/products//[EMAIL PROTECTED]'casual']
to get to a pure XQuery solution. I personally like the solution
of DB2 better though. Or do you have another option?
The way I envisioned this mapping is that elements represent
attributes of tuple, so nested attributes were attributes of
attributes, and therefore joins. I'm not swapped in on the industry
practice in XQuery/relational mappings, though I'll pester the Oracle
folks in the XQuery WG for more info.
If you map relational data that way, content of the table will be
seen just as that. You would want to use XQuery if you're dealing
with XML, which will reside in a specific cell. If you would
implement it this way, you still can query that XML, loosing the
whole purpose.
I'm not aware that Oracle has XQuery support in their relational
database. As far as I know they only support that in a specific
Oracle XML DB and in Berkeley XML DB. To my knowledge, the only
mayor DB that supports this is IBM DB2 and they don't do relational
mapping in XQuery. Instead they do an SQL query with and import of
XML residing in a column to be used in the XQuery statement.
However, if you want a pure XQuery solution you will need mapping.
I like DB2s solution much better and therefore I think that allowing
additional parsers to be integrated in the current parser would be
the best solution. Not only do you not have to do relational mapping
where it doesn't belong, it also solves the API problem discussed
earlier.
If you asked the same question about SPARQL, I could do a better job
answering your question as that's the sort of code I write.
I don't know enough about SPARQL to ask intelligent questions about it.
Best regards,
Arnold
