Re: Ideas for World Hierarchy Example

Marshall wrote:
> On Jan 12, 7:41 am, "Neo" <neo55..._at_hotmail.com> wrote:
> > > > Its almost as though there is a concious disrespect in some parts of
> > > > the community to the years of effort, hard work and diligence of those
> > > > who preceded us.
> >
> > > Disrespect? Sure.
> > > But I'd say that plays second fiddle to plug ignorance.
> >
> > I think fundamentally Dawn is pointing out that non-RMDBs [...]
> > are di-graph-ish and are possibly better for some types of
> > applications. Why is this being ignorant?
>
> I wasn't speaking of Dawn per se. But suppose someone makes the
> claim that X is possibly better for some types of Y. Why should
> I even care? I watch a lot of TV, I hear a lot of radio, and I surf
> a lot of sites: I hear approximately one million product claims a day.
> *Claims* do not interest me; I am interested in empirical evidence,
> comparative study, and theoretical foundations. These things are
> available, or one can do them oneself.
>
> It doesn't have to be a ten million dollar HBS comparative
> longitudinal study, either. Someone who wanted to convince
> me that I should pay attention to some other data model
> could simply post queries that are hard for SQL and easy
> for their system.

This won't convince you, but a couple of tidbits...any time there is negation across rows, such as listing all students who do not have a major of PHIL, which can surely be done in SQL, but in MV is

LIST STUDENTS WITH EVERY MAJOR <> 'PHIL'

or queries including many-to-many relationships, or any time you would like the result set (bag) to include multiple lists (such as property lists) for the same entity, but where the lists have nothing else to do with each other, such as with the MV statement

LIST PEOPLE CARS CHILDREN Where the result would look like

Jane Doe    Saturn               Mary
                  VW Beetle        Susan
                 Mustang

you have much easier queries in MV than SQL. In any case, the end user typically has a very easy query or none that will work for them until a developer gives them the vocabulary item to make the query work and work easily. This is quite a different concept than SQL, where you can ask everything, but you might have to have many years of experience before you can get it right consistently. With MV/Pick, the end-users actually do write most of their own queries and do so handily.

> And their SQL better be damn good, or
> it'll get picked apart in short order, either by me or by
> a whole host of people here who are a lot better at SQL
> than I am.
>
> A lot of people have come through here with a lot of alternative
> ideas, and so far the number that has impressed me is exactly
> one: Vadim's relational lattice approach, which I note is
> *excruciatingly* well-grounded in mathematics. One of the
> very first things I read about it was its algebraic properties:
> commutativity, associativity, idempotence, asborbtiveness.
>
> Consider some other approach to data management, or
> even general computation. What are its primitive operators?
> Is the set provably minimal, or is there some redundancy?
> What algebraic properties do they have? What useful theorems
> can we derive from these properties? What is the computational
> power? It is the same as first order logic, untyped lambda
> calculus, what? What is the computational power of the type
> system? What interesting theorems can it prove about
> source code? What is the concurrency model? How does it
> compare to shared-state concurrency, or transaction isolation,
> or message passing concurrency? What is the constraint
> system like? How does it integrate with the type system?
> What constraints can be proven statically?
>
> These questions are interesting.

The questions I really find interesting are: How long did it take to write that software application? How many developers were required? How much experience did developers need and how much training? How long does it take to maintain the software in various ways? How long does it take to write another using and extending the same database? How much additional time does it take to make the software sing for the end-user compared to what is easiest to do that works, but isn't great?

And I would really like is some emperical data showing what it takes to make various types of changes within or extensions to various types of software using different languages, data models, or database products (or data exchange approaches, or IDEs, or ...)

> I wonder if maybe a digraph-ish approach is better
> for some kinds of applications?
>
> That question is not interesting.

I do think it is interesting, although perhaps more interesting for an emperical research effort than a theorectical one. cheers! --dawn

>
> Marshall
Received on Fri Jan 12 2007 - 19:32:56 CET