Hi,
I stand corrected, Oracle does support XML in their relation DB. I've
seen some of these articles before, but mistakenly understood that is
was a separate DB. My experience of Oracle doesn't go much further than
playing with XE. If I understand the example correctly you would query
XML data in a blob (mytable.productlist) as:
XQuery for $i in ora:view("mytable")/ROW where status="abc" return
<item>{$i/productlist/product/description}</item>;
or
SELECT XQuery("for $i in $y return
<item>{$i/product/description}</item>" PASSING productlist RETURNING
CONTENT) FROM mytable.productlist WHERE status="abc";
So basically Oracle has the object relational mapping as I suggested it,
expect the child nodes of the table is ROW, which is much more logical
and it uses an XQuery extension ora:view() instead of doc(). Integration
of an XQuery statement in an SQL query is also possible as IBM DB2 does.
In any case, Oracle uses a specific keyword, XQuery, to select a
different parser. I really think that is the way to go, regardless of
you do or do not want to embed the XQuery statement.
Best regards,
Arnold Daniels
Ken Jacobs wrote:
> Arnold, you wrote:
>
> 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.
>
> Oracle does indeed have XQuery support in the relational database, and
> has had since Oracle9i, some years back. Oracle was the FIRST
> relational database to do so. This is NOT a separate server,
> separate store or separate system at all, but is tightly integrated
> with the relational database. It supports XPath expressions, XQuery,
> an XML schema and a repository model. You can use SQL to access XML
> data or XML to access relational data. With the recently-announced
> Oracle11g, there are now three options for storing XML data:
> object/relational (shredded), BLOB, and a new optimized binary XML
> format. Each serves a different use case. I believe Oracle's XML
> capability has far more functionality and performance, and has a track
> record of much broader and significant customer usage, than IBM's DB2
> XML extender (which, unlike Oracle's product) is not free ...
>
> See the Oracle XMLDB home page
> <http://www.oracle.com/technology/tech/xml/xmldb/index.html> for more
> info.
>
> Thought you'd want to know.
>
> Regards,
>
> Ken
>
> Arnold Daniels wrote:
>>
>>
>> Eric Prud'hommeaux wrote:
>>> * Arnold Daniels <info@stripped> [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//product[@type='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
>>
