Re: What is the logic of storing XML in a Database?
Date: 29 Mar 2007 11:26:51 -0700
On Mar 29, 9:43 am, "Cimode" <cim..._at_hotmail.com> wrote:
> On 29 mar, 17:29, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> > 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
> where *schema1* would contain all query information characteristics.
I think of it as being something implicit, rather than explicit. When you execute a client program, the runtime can inspect the client and issue the "Pull()" to the dbms at connect time.
> The client would have also presentation routines that would allow it
> to bind the schema to any kind of local presentation method.
And these bindings would be declarative, and probably expressed as relations. And they could be dynamic, such that if you have a table widget bound to a table/view/query, as the table was updated, that would be reflected in the contents of the widget, dynamically.
> 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)...
I didn't quite understand this part. I usually think of clients as having the schema they are written against "built-in." This makes it sound like clients are using dynamic schema. That makes sense for ad hoc queries but not so much for client code, which I think of as fixed.
Marshall Received on Thu Mar 29 2007 - 20:26:51 CEST