On Sun, Feb 25, 2001 at 10:37:10AM -0600, Cal Evans wrote:
> Glorious Sunday morning greetings to you Jan,
> 
> No, XML is a format for 2 different applications, usually 2 totally separate
> applications, to be able to exchange data. It is not an appropriate choice
> for storing large amounts of data that will have to be queried. Nor is it an
> appropriate choice of language for talking to an RDBMS.  Outside of the fact
> that it can be extremely verbose, we already have a perfectly good language
> for that, SQL.  SQL is a language for committing data to a storage mechanism
> and retrieving the data back. It is superior to XML in those tasks.

SQL ist tighty coupled with _relational_ database design. Which has its
advantages, but also a lot of shortcomings. 
Every time I am dealing with a tree structure (Which is quite common - thing
of document handling in folders, an access system using groups of groups, an
webmailer usings folders, mails, attachments,....) I either need to to a
_LOT_ queries when parsing through the tree, or I need a very complex logic,
and still quite a few queries.

Most data people are dealing with is much more suited for XML than for an
RDBMS.

> Again, if you have need to talk to your RDBMS via XML then a thin wrapper
> written in the language of your choice is the proper way to go. This allows
> you to do your job without bloating my application with unnecessary code.

<ironic>
Maybe my application does not need the power of SQL, but always does a full
scan over the whole table, thus the only SQL-Statement used is "select *
from table".

I don't want my application to be bloadt with your bloody SQL, so lets just
take the SQL-Parsed/Engine out of the DB, and make them a client-side
library.

Actually, I also do not need locking implemented in the db, since my
application is just used by one person, so this should be handles by the
client too.

And all those datatypes in Mysql... Why do we need them... We just need
BLOBs, we then can just create PHP-Objects with the necessary data, and
store them in one big BLOB (of course after a call to serialize() ).
</ironic>

> And I also disagree with your statement that there is no difference between
> metadata and data. there most certainly is. But that's a discussion for
> another thread.

Would you consider formating/layouting information in an document data or
meta-data?

I guess for an word processor (or even an text editor) ist meta-data.

But for an DTP-Programm it sure is data.


I want an DB which helps me storing structured data efficiently, and I think
XML could be part of the solution.

greetings, Florian Pflug

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to