Re: Do Data Models Need to built on a Mathematical Concept?

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0305030932.21e8f09e_at_posting.google.com...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message news:<1eSra.148357$Si4.121419_at_rwcrnsc51.ops.asp.att.net>...
>
> > But I perhaps you mean D-style (vs. SQL-style) tables?
> > That's what I was suggesting.
>
> I mean relational style vs. XML hierarchical style.

I think we agree that this would be a good thing.

> > If we are to have stardardized interchange, we have to be able to exchange
> > semantic data (schema) as well as the base data.
>
> But we don't need a standard catalog, only a standard DDL.

Hmmm. I guess that's true. But is having a standard DDL any better than having a standard catalog? If we have a standard catalog, we can work with schema updates in exactly the same way we work with any other data update. OTOH, maybe the only way we can work with generalized data updates is in some language.

I observe that it's easy to model inserted rows as relational data. (Trivial, in fact.) But it's harder to model delete and harder still to model update. Maybe this is an argument for using a language to do it. For example, some dbms implement replication via shipping each line of SQL to each replica.

> > For example, if I ship you
> > some tables, you might want to manipulate them and send them back.
> > If that happens, you'd probably like to be able to do some validation on
> > your side before sending them. You can't do that unless you know
> > the domains, the foreign keys, the constraints, etc.
>
> And we can declare all of that with the DDL.

Okay, true enough.

But to do it this way seems an admission of failure to me. After all, this is data that is *easily* represented as relations, and here we go, falling back on a textual representation.

I'm conflicted.

Marshall Received on Sat May 03 2003 - 20:50:32 CEST