Re: What is the logic of storing XML in a Database?

From: Cimode <cimode_at_hotmail.com>
Date: 29 Mar 2007 10:43:58 -0700
Message-ID: <1175190238.098843.180970_at_p77g2000hsh.googlegroups.com>


On 29 mar, 17:29, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> On Mar 29, 6:52 am, "Cimode" <cim..._at_hotmail.com> wrote:
>
>
>
> > View network sharing seems however to be the only fundamentally
> > optimal solution. The receiver of some EDI information is simply a
> > remote user from the perspective of the dbms. In such perspective,
> > defining views the receiver can interpretate and openning the right
> > ports (with an adequate TCPIP topology) is much simpler than adding an
> > entire applicative layer to handle the *carrying* of some
> > encapsulated message. In other words, I strongly doubt of the real
> > need for sending a message (be it CSV or XML or anything) as opposed
> > to simply sharing a view.
>
> I strongly agree.
>
> I'll go a bit further. I imagine a world where the schema that
> a given piece of client software is embedded in that client.
> When it connects with the dbms, it tell the dbms the schema
> it expects, and the dbms dynamically constructs a view for
> that client, if possible.
>
> Marshall
If you allow me I shall go further in your dream...

In such word, each client routine code would be as simple as

Pull.db1(schema1)

where *schema1* would contain all query information characteristics. The client would have also presentation routines that would allow it to bind the schema to any kind of local presentation method. Periodically, clients would be able to gather existing schemas according to areas of interest using simple routines such as

Pull.(AllSchema, AreaofInterest)

Given the amount of space and resources saved, the client could easily and punctually renew such schemas...Some kind of language would require to be created for that (or maybe an extension of a relationnal querying language)...

... Received on Thu Mar 29 2007 - 19:43:58 CEST

Original text of this message