Re: TRM - Morbidity has set in, or not?
Date: 18 May 2006 15:55:09 -0700
Message-ID: <1147992909.807876.77120_at_i40g2000cwc.googlegroups.com>
erk wrote:
> dawn wrote:
> > If such a programming language
> > has RDM as only one of several ways of modeling and working with data
> > in large shared data banks, then the RDM loses the exclusivity it seems
> > to demand, however. So, is the RDM sub model you mention one that is
> > still the only way to view persisted data, or simply one way? For
> > example, could XQuery (or similar) and SQL (or a better implementation
> > of the RDM) function side by side in a language that works with large
> > shared data banks without violating the RDM?
>
> I don't know about XQuery (which is meant for XML values), but
> certainly most UIs are a tree view of data, of which a relational
> database can support many (different restricted views of the same
> data). However, updates to data need the same constraints as the
> database itself, so from that standpoint, the application is a node of
> a distributed database.
OK, I'll accept that database-centric view of software products (from you ;-)
> But for presentation, different languages make a lot of sense.
>
> > > The programming language also needs a highly developed process model at its
> > > core. The object oriented process model provides a good starting place.
> >
> > Agreed.
>
> What is an "object oriented process model"?
I thought I'd let his description pass through since I think I know what he means by it. My interpretation was that David was simply indicating that there needs to be a way to address functions and not just data Whether you want to say an OO language has a process model is neither here nor there. It is difficult to "get" OOP until you understand main() so you can see where you step through from beginning to end, aka process. Every software product is a big F(input) = output. You need to address F as well as input and output.
> > XML and JSON are indications that we might have moved beyond the
> > simplest of forms for communication of bulk data between systems,
> > however, as there is no need to put data in what-was-once-called-1NF
> > for data exchange (and no one suggests otherwise, as best I can tell).
>
> I'm not sure what would be so different now, and I don't really see
> that XML is an advance.
Yeah, yeah, XML sucks and all, but it has a data model that permits structures, such as lists, beyond what SQL92 permits. One advantage in passing a single message as an XML document or in JSON is that you do not need to have the redundancy found in a single SQL(-92) view that needs to pass multivalued data. Think of a message using the RM (in 1NF as previously defined) and one using XML (which is grossly redundant with the metadata I recognize) or JSON for data that might be described by:
Person
personId
name
cars: list (ordered by frequency of this person driving that car) emailAddresses: list
phoneNumbers: list
Surely you see the advantage in a single message with 10,000 such persons not dealing with the cross-products of the three lists in a single (SQL92-like) relation, right? That was my only point.
> I still see plenty of cases where
> comma-separated values are more than sufficient, and properties files
> (e.g. in Java apps) usually easier to read and write than XML
> configuration files.
Agreed.
> S-expressions are fine, rich structures, and date
> from long before the relational model.
Yup.
> > With more richness in the current RDM, are there any folks using it for
> > data exchange, employing set processing commands for data and
> > constraints, for example?
>
> I don't think the RDM has changed radically; the richness derives from
> user-defined types which Codd identified very early,
I'm referring to ditching the old definition of 1NF and adding NEST & UNNEST-like functions, for example. Perhaps it would be less likely to prompt disagreement to state that there is more richness in the current implementations of the RDM due to the changes (that might have happened many moons ago) in the RDM that are or have taken their time seeing the light of day.
> and from proper
> use of relation-valued attributes (RVAs). Beyond that, the tree
> structure of an XML document doesn't capture anything additional; it
> is, perhaps, better suited to naturally hierarchical data. But most of
> the XML I see in practice communicates (badly) either a graph,
typical if designed from scratch
> or
> relations (via ID/IDREF and cobbled-together versions of these).
In an attempt to integrate relations into the mix.
> Date
> identified a simple XML encoding of relations.
The other direction being more difficult, of course.
> Constraints and commands are different, but constraints should be
> carried with the data.
It's bad enough for XML to carry names (very simple metadata) with data as it does. How would you propose those constraints get passed around with the data? Individual objects? Ugh. We would definitely long for comma-quote.
> However, this would require a standard language,
> for complex constraints not capable of being encoded with simple tags.
and a better way to associate metadata (e.g. constraints) with data than repeated tags.
Cheers! --dawn Received on Fri May 19 2006 - 00:55:09 CEST