[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

[main] SQL instead of XQuery

• From: Dmitry Turin <dev3os@n...>
• To: xml-dev@l...
• Date: Thu, 7 Feb 2008 10:43:32 +0200

Chris,

First of all, let's distinguish
1) binary (rational) _data format_ and xml format
2) SQL _syntax of request_ and XQuery syntax request
3) rational _model_ and xml/dtd model
4) rational _core of engine_ and xml core of engine

---

>> But today's needs consist of merging rational and xml in one engine:
>> rational for structurized (and predictable) data,
>> xml for arbitrary (and not predictable beforehand) data.
CB> XML data is or can be as structured and predictable

Here speach goes about model !
It's not needed to develop engines for xml/dtd model for predictable data,
because engines, supporting rational model, ALREADY exist.
Xml/dtd model of storing has sense only for non-predictable data,
i.e. __when table with name, identical to name of inserting element,
does not exist__.

CB> mapping from relational data to XML data, but not
CB> vice versa

  Rational model is graph, but xml model is tree -
so xml model is sub-set of rational model (i.e. you are wrong).
  Of course, you can point artificial exit from this situation:
to use PrimaryKey-ForeignKey mechanism in xml attributes.
  So two model are identical in this ?

  Let's prolong comparison.
  Presence of DTD for xml model is equivalent to such limit
in rational model, that inserting is possible into only
existing tables.
  Vice versa, absence of DTD is equivalent to
auto-creating of new table and auto-altering of it,
when table name is mentioned as name of inserting data
(as name of inserting xml-element).
  If we enter mechanish of auto-creating/auto-altering of table,
there is nothing difference between models ?

---

CB> store all your data [xml and rational] in one engine
+
CB> you should be storing all your data [xml and rational] in an XML database.

  Here speach goes about format !
  Xml is text, and it occupies more place, than binary data.
It's reasonable to archive this text. One way is to use
archiver (e.g. zip, etc), other way is to convert into
binary form.
  These ways are not equivalent.
*) Second way is more clear for man,
naturally understandable for processor
(non additional code with additional human mistakes).
*) Second way hasn't redundant un-archiving and archiving again.
But engine can't apply second way for non-predictable data
in traditional rational model (without auto-creating/auto-altering).
  What choice should be made for non-predictable data (?):
1) skip it
2) auto-create/auto-alter table for it
3) archive and un-archive it
4) save in textual form
  It depends of frequence of non-predictable data.
Now we have, that these type of data is very seldom !!
So both 3) and even 4) variant are acceptable.

---

>> >> I propose to use SQL instead of it
>> CB> SQL is a second, foreign query language to XML databases ...

Here speach goes about syntax !
One engines can use SQL5, while other engine can use XQuery.
But these languages are not equivalent.
There exist much libraries of SQL (SQL 1-4) code ;
there exist much applications, writing under SQL;
but XQuery is relatively new.
So preference should be given to SQL _syntax_.

Problem is only one: protection of investment, invested into
XQuery syntax of storages.

---

  Look at paragraph above,
which is about frequence of non-predictable data.
This frequence can be changed during developing of business project,
during transformation of business task.
As you said, one engines process predictable data
(rational in your transcription) better,
while other engines process non-predictable data
(xml in your transcription) better -
so we need portability of data from engine to engine,
i.e. we need compartibility between engines in syntax.



Dmitry Turin
HTML6     (6. 5.3)  http://html60.euro.ru
SQL5      (5.11.0)  http://sql50.euro.ru
Unicode7  (7. 2.1)  http://unicode70.euro.ru
Computer2 (2. 0.2)  http://computer20.euro.ru

• References:
  • [OT] bugs in JDK regex engine ?
    • From: "Mukul Gandhi" <gandhi.mukul@g...>
  • RE: [OT] bugs in JDK regex engine ?
    • From: "Michael Kay" <mike@s...>
  • Re: [OT] bugs in JDK regex engine ?
    • From: "Mukul Gandhi" <gandhi.mukul@g...>
  • RE: [OT] bugs in JDK regex engine ?
    • From: "Michael Kay" <mike@s...>
  • Re: [OT] bugs in JDK regex engine ?
    • From: "Mukul Gandhi" <gandhi.mukul@g...>
  • SQL instead of XQuery
    • From: Dmitry Turin <dev3os@n...>
  • Re[2]: SQL instead of XQuery
    • From: Dmitry Turin <dev3os@n...>