On Thu, Apr 19, 2007 at 09:08:27AM +0300, sql4-en@narod.ru wrote:
> >In particular, XML is actually miserably bad at capturing certain
> >kinds of relations between items.
>
> Write examples, please.
>
> P.S. By the way, XML is mentioned as tool for traffic (for transport).
> But i agree to forget about that to learn what are you imply in your
> quoting.
That's irrelevant to what you are proposing, because what you are
proposing is to alter SQL -- or at least, PostgreSQL -- to break the
relational model of SQL in order to make it look more like XML.
An obvious example of the way XML is not _good_ at expressing kinds
of relations is that it simply doesn't have a way of expressing
foreign key relations. If you want that sort of thing, you write a
DTD that somehow says two things go together; but it can't enforce
it, because that has to be left to the implementation. Moreover,
since you seem to want to make this perfectly generalizable to any
XML at all, what you really are saying is that you'll give up the
feature.
Every time someone helpfully comes along and says that SQL doesn't
"really need" this or that feature because of some special purpose
application that they have dreamed up, I have exactly the same
reaction: those proposing picked a SQL database because it's what
they had, rather than what they need. This case is no exception.
You have so far completely failed to explain why any of what you are
proposing ought to be stored in PostgreSQL in the first place. What
is wrong with flat files? Or bdb? Or something like that? Not
every datum belongs in a relational database.
More importantly. . .
> You don't understand, i speak not about SQL!
>
> Problem consist of transportation data, received by SQL, into external
> world.
. . .you have completely missed the point of SQL, then. It's a
special-purpose language, unconcerned with transport, that is there
to perform queries on relational data. If you want some magic
transport thing that doesn't need a special library to get it out of
Postgres (and you seem here to have completely overlooked that you
_always_ have to have one: someone who won't learn DBI and won't
learn SQL sure as heck isn't gonna learn enough C to program libpq,
which is actually how you talk to the PostgreSQL back end), then
write that. Don't bollocks up the back end and change the syntax of
SQL to achieve what is, IMNVHO, a really bad idea.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
Users never remark, "Wow, this software may be buggy and hard
to use, but at least there is a lot of code underneath." --Damien Katz
