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

From: David Cressey <>
Date: Thu, 29 Mar 2007 19:11:29 GMT
Message-ID: <BbUOh.3523$E46.3411_at_trndny09>

"Marshall" <> wrote in message
> On Mar 29, 6:52 am, "Cimode" <> 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.

I have done this, albeit in a very clumsy and primitive way, some 10 years ago.
In this case the "client software" was MS Access 97, and the server DBMS was Oracle.

Access supports "table links" which, in effect, are remote views. Oracle supports remote tables.
There's the transport layer.

I didn't have any automated way of creating the correct view for the app, but essentially a manually devised "CREATE VIEW" statement was good enough. The lack of parameters on views slowed me down a little, but there are workarounds.

The apps built on top of Access were very simple minded pull the data, make a graph, or write a report type things, with a few data entry screens for good measure.

I realize that this is just the tip of the iceberg compared to what you are contemplating, but it's amazing how much could be done with no more than this! Received on Thu Mar 29 2007 - 21:11:29 CEST

Original text of this message