Re: Resiliency To New Data Requirements

dawn wrote:
> Marshall wrote:
> > dawn wrote:
> > >
> > > I agree. If we are going to start somewhere and move forward, we might
> > > be well-served to look to what works today outside of the RM (even
> > > though it, of course, typically markets itself as relational). Is it
> > > less expensive to work with Cache' than Oracle given such and such an
> > > environment? If so, why?
> >
> > Is there theory behind any of this? Any mathematical models or other
> > formalisms? It seems to me that comparing Cache with Oracle for
> > TCO is not on-topic on c.d.t.
> >
> > Does any of "what works today outside of the RM" have any theory
> > behind it? This is a theory newsgroup after all.
>
> Hi Marshall. The reason I originally came to this list was to learn
> what it was about the theory that lead the industry down a path of
> throwing out some good features such as lists, which I have used as my
> primary example. I learned from this forum and elsewhere that the
> theory has come back around to now permit nested structures, while a
> huge amount of software implementations are stuck, for practical
> purposes, with the flawed theory of what was once known as 1NF.

I think the initial interpretation of 1NF was confused rather than 'flawed' - at the end of the day all theories are developed iteratively. Of course in math, a relation can contain an element from any domain, and once RM became established this was picked up on relatively quickly. I think it's pretty much accepted now that how one operates on that complex element is not within the remit of the RM itself, and as such the DBMS must handle its decomposition. And of course that's the way it should be given that dates, strings and other decomposable types have no relevance to relational theory.

>
> So I want to talk about theory and its relationship to practice. We
> don't need another two decades of flawed tools that blindly try to
> follow another flawed theory. The industry had lists, then pooh-poohed
> them, and now is bringing them back, where "the theory" seems to now
> permit nested sets (although there are still many who are not ready to
> accept that extension of the theory), and lists are accepted if defined
> as user-defined types. But there are still no list operations in the
> theory as best I can tell. If theory people want to discuss theory
> sans "end users" of the theory (like me), they can do their work in a
> vacuum, but then perhaps the industry would be well-served if more of
> it (than in the past) would stay there so we don't repeat the mistakes
> of the past (e.g. normalization as originally defined being implemented
> before it was ripe).

I've seen you refer to this as "throwing the baby out with the bath water". I'm not sure at all thats a good analogy, as it infers that complex types were the most important factor involved - if they had been RM would have seriously struggled, whereas the other important advantages of the model over its competitors proved to be overwhelming, and it dominated in good old darwinian fashion.

Unfortunately recent 'advances' in db work such as XML databases seem to be attempting to retrieve the 'baby' by rebuilding a bathroom without any planning schematics, installing an upside-down bath and, worst of all, no plumbing system.

>
> So, while I want to talk about theory and its relationship to practice,
> I'm not developing theory, and I don't know the totality of the theory
> behind any di-graph models, for example. I suspect that there are many
> here who would not accept anything other than set theory (functions are
> sets, so I'm sure anything software developers do can be modeled as
> sets if someone has a reason to do so.)

Well, graph theory is constructed from set theory itself, a graph being defined as a triple (set of inputs, set of outputs, set of edges). It has a powerful theory layered on top of this definition and is hence applicable to a whole range of practicalities. Unfortunately information handling is not one of these , given some information relationships will not fit into a binary approach such as graphs at the logical level*. Believe me, I spent an an incredibly frustrating year attempting to 'make them fit' before conceding defeat - looking back it seems a very naive period, but it was an invaluable education.

Jim.

(* That is apart from 'hypergraphs', which uninvuitively allow edges to connect > 2 nodes, so allowing the handling of n-ary relationships. However, then the set of edges essentially become a set of tuples - an n-ary relation, and we are left with somewhat of a reinvention of relational theory.)

>
> Did that clarify? If so, is that, or is that not a valid discussion in
> this forum? (Don't worry, even if you suggest it is valid to discuss,
> I will still keep a low profile here as I know there are some who
> really, really dislike having me around and I prefer the company of
> those who are at least civil in their discourse when they disagree with
> someone, as you, David, mAsterdam, JOG, x, and many others have always
> been).
>
> Cheers! --dawn
Received on Thu Aug 10 2006 - 18:55:34 CEST