Re: Nulls, integrity, the closed world assumption and events

From: dawn <dawnwolthuis_at_gmail.com>
Date: 22 Jan 2007 11:51:19 -0800
Message-ID: <1169495479.357184.282210_at_v45g2000cwv.googlegroups.com>


Marshall wrote:
> On Jan 22, 7:29 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
> >
> > I agree. What do you think of products such as Intersystems Cache'?
> > What would you suspect (or know) might be missing for such a product to
> > meet your needs? --dawn
>
> Hey Dawn,
>
> I note that your speculative, discursive style of essay hasn't been
> received with much favor here. Would you consider another
> approach? Would you consider the possibility of addressing
> specific problems and providing specific solutions? You could,
> for example, pick some common problem domain, invent a
> conceptual schema, propose a logical schema in an MV approach
> and a SQL approach (and possibly a Tutorial D approach.)
> The SQL you come up with could perhaps be polished by
> other people; maybe you could use some of your MV
> acquaintances to polish the MV queries.
>
> For example, I often think of problems in terms of a schema
> with Customers, Invoices, and InvoiceLineItems. These are
> familiar to anyone who has ever bought anything, so they
> have the advantage of being a common ground for discussion.
> (As well as being a very real-world application of data
> management.)
>
> One problem I have with a lot of your posts is that they are
> very abstract and nebulous.

Yes, I recognize that I have not laid out a specific clear defense of everything I've stated (nor does anyone else, but if everything you say assumes we are working exclusively with set-based processing, there seems to be no need to give rationale in this forum). I tried to address this somewhat with some blog entries. I haven't had a lot of time to do so of late, but the aggregate of what I have written is likely better than anything I can provide quickly here. 2, 8, & others listed below give specific examples.

> We traded lists of questions a
> short time ago, and I couldn't help but notice that most of
> my questions had definite answers, and most of yours didn't.

Yes, the questions I raised were difficult to answer.

> This idea would make the discussion more concrete. If you
> have the courage of your convictions,

Please recognize that I discuss these issues in order to gain convictions. Not all of my opinions fall into the "convictions" category. After a few years of reading and asking, I'm up to 3 items that make it into that category (that the industry should ditch 3VL and 1NF-as-traditionally-defined, and should add lists).

> you should to be able
> to demonstrate a variety of situations where MV works better
> in the small, rather than just giving anecdotes about how well
> you feel it works in the unmanageable-to-compare large.

Perhaps some of my blog entries below help, but I'm sure there is still a lot of work to do.

> It wouldn't even have to be a particularly theory-based
> dialog. Just propose a problem, build a schema in MV
> and SQL, build some challenging queries in MV and SQL.

Queries, of course, only gets at some of the issue, but I will continue to work on this.

> MV does have a fairly standardized query language, does
> it not?

Yup.

> What do you think?

Do you think I have done some of what you are asking in the aggregate of the blogs below (I recognize they are not shaped as you might like with example, schema in various models, queries in each model, but I at least tried to give some examples.)? Queries are not my only issue, but perhaps you would like more examples than already provided.

I'm also wondering if some of the XQuery research would help in that regard so that I'm not writing in a language that is likely more a part of history than the future (sadly). XQuery addresses a similar, but more complex, data model. Maybe the type of clarity you seek is in the write-ups for why IBM decided to implement XQuery when they already have SQL. I've found a few papers, but perhaps someone else knows of papers that would fit the bill for the type of arguments that those here would expect.

There are a lot of people working on XQuery and considerable research in that area, but not many speak up in this forum regarding XQuery or the data model it addresses. For example, I have not seen examples of why or how one would structure data that could be queried with XQuery but not with SQL. Why is that? Just wondering out loud, as I would like to see a dialog between the theorists in this area and those who want to stick with only set-based approaches.

--dawn

P.S. [Blatant blog promotion, but only placed here in case it is helpful] The following are the blog entries I have written to date. No one of them is sufficient to give a good enough hint of why one might model data for implementation in something other than a product that was written to implement the RM. But taken together, I hope there are some more hints than what can be provided in any single posting here.

  1. Is Codd Dead? http://www.tincat-group.com/mewsings/2006/01/is-codd-dead.html Just an overview of a perspective not often on cdt, but with visibility elsewhere.
  2. Who Ordered the Ripple Delete? http://www.tincat-group.com/mewsings/2006/01/who-ordered-ripple-delete.html An example, as you have requested, small as it is.
  3. The Naked Model http://www.tincat-group.com/mewsings/2006/01/naked-model.html Definition of terms, which I have since found aligns better with Pascal's defs of the terms (though not exact, I'm sure) than with many others in the discipline. Also makes clear that the RM is not necessary for s/w development.
  4. The Data Movement http://www.tincat-group.com/mewsings/2006/01/data-movement.html Lament on the switch from "data processing" to "computer science" and other terms.
  5. The Model Behind the InterFace http://www.tincat-group.com/mewsings/2006/02/model-behind-interface.html Look at the data model behind a user interface (rather than a DBMS). Indication of why the RM is not sufficient as a data model for s/w development.
  6. Don't Suffer Impedance http://www.tincat-group.com/mewsings/2006/02/dont-suffer-impedance.html Conclusion from 5 & 6 that the RM is not sufficient (therefore, it is neither necessary nor sufficient.
  7. The LIST of GIRLS http://www.tincat-group.com/mewsings/2006/02/list-of-girls.html An aside related to the history of Pick, one non-RM model.
  8. Data for Every 1 http://www.tincat-group.com/mewsings/2006/03/data-for-every-1.html Specific example of an SQL query compared to an MV query.
  9. In Every Job That Must Be Done There Is a Data Element of Fun http://www.tincat-group.com/mewsings/2006/03/in-every-job-that-must-be-done-there.html Derived data the MV way, showing one significant difference between MV & SQL.
  10. With Data Modeling, What's Your Bag? http://www.tincat-group.com/mewsings/2006/03/with-data-modeling-whats-your-bag.html Definition of terms and a bit about lists, setting up a specific example.
  11. Better to Have No Values http://www.tincat-group.com/mewsings/2006/03/better-to-have-no-values.html Use of 2VL instead of 3VL, specific example.
  12. Consuming Frozen Data http://www.tincat-group.com/mewsings/2006/04/consuming-frozen-data.html Data marts, OLAP and setup for the next blog entry.
  13. Surf and Turf Reporting http://www.tincat-group.com/mewsings/2006/04/surf-and-turf-reporting.html Reporting against some frozen and other live data (not highly specific to question about SQL vs anything else)
  14. Constraints Factored In and Out http://www.tincat-group.com/mewsings/2006/05/constraints-factored-in-and-out.html Pulling constraints out of the DBMS schema, into the data.
  15. To Whom Should Size Matter? http://www.tincat-group.com/mewsings/2006/07/to-whom-should-size-matter.html A look at one rather silly and rarely necessary constraint that seems to be considered highly relevant in DBMS's that have tried to implement the RM.
  16. Cowboys With Promiscuous Databases http://www.tincat-group.com/mewsings/2006/11/cowboys-with-promiscuous-databases.html Undoubtedly too "high level" for this crowd, setting up discussion of differences in logical data modeling for MV compared to logical data model for an SQL-DBMS
  17. OTLT: Metadata Piece Not Apartheid http://www.tincat-group.com/mewsings/2007/01/otlt-metadata-piece-not-apartheid.html One specific example of how one might use a different approach to modeling data for MV compared to SQL.
Received on Mon Jan 22 2007 - 20:51:19 CET

Original text of this message