Re: One Ring to Bind Them

From: Chris Hoess <choess_at_stwing.upenn.edu>
Date: Fri, 18 Jun 2004 03:04:24 +0000 (UTC)
Message-ID: <slrncd4mtn.e2r.choess_at_force.stwing.upenn.edu>


In article <40d07bda$1_7_at_corp.newsgroups.com>, Bill H wrote:
> Eric:
>
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:h2Zzc.1822$Pt.1440_at_newssvr19.news.prodigy.com...
>
> [snipped]
>

>> English is a poor basis for automation, and
>> defining a useful subset would get us into even murkier water than the

> c.d.t
>> glossary. Nonetheless, relational offers a more useful basic structure

> (the
>> predicate, which is a sentence) than Pick/MV, which aspires to nouns.
>> Objects also aspire to be nouns, leaving verbs and sentences

> "encapsulated",
>> whatever that means (I know that it means, but doubt its utility in all
>> things).

>
> ...a more useful basic structure? Some solutions, yes; some solutions, no;
> some solutions, debatable. Most competing systems have unique benefits and
> this is no different. The question: is the application the best place to
> store business rules in a lanquage understandable to those defining those
> rules?
>
> You state no (I think). I state yes! There is a tremendous cost advantage
> for my position, but as I've said before, cost is not an issues in all
> scenarios. The view that the RDM is more useful is tautological. In other
> words, a primary axion is: it is. So one has no alternative but to conclude
> so.

Huh? I think you've missed Eric's point. As he said, the relational model is based on predicates: sentences which make a single, descriptive assertion. I confess that I don't fully understand the correspondence between Pick internals and parts of speech, but the point is clear nonetheless: our task in compiling databases, as I see it, is to be able to accurately describe relevant parts ofthe world and draw inferences from those descriptions. It is from this premise that Eric's conclusion follows: the best model for making descriptions of things is that whose basic unit is description.

I'm not 100% sure how it follows that storing constraints in the database of necessity results in a disadvantage in costs. As I just posted in another followup here, the constraints themselves are easily accessible to the applications given a good system catalog. For that matter, it doesn't follow that the constraints must be presented exactly as represented internally in the database. It seems to me that it should be possible to make a 1:1 mapping of some terse, "programmer-friendly" language into a more English-like statement of the constraint, suitable for checking by "domain experts".  

>> > 3) While hiding much that should be hidden, it "feels like" so much gets
>> > hidden that people spend time trying to figure out how it does things in
>> > order to be good at writing declarations

Is this universal, or is this just a by-product of SQL's redundancy and the need for SQL query optimizers? (e.g. can we build a system where all logically equivalent statements in this declarative language run in more or less the same amount of time, and if so, will that stop people from trying to outguess the compiler?)

> These are areas where I would want to defer to IT professionals. All I'd
> like is to use the function to accomplish my local business task; as Dawn
> noted, a date function. The date is stored in the database internally but
> the functions work miracles extracting the various pieces of a date.
>
> In the MV model the dbms contains numerous functions to allow data
> extraction. This is the benefit with the dbms being both a database and an
> application server and a development environment. These functions become
> part of the data when applications are developed.

I'll have to go back home and look, but I wonder if much of this would be soluble by TTM's elevation of views to first-class relational citizens, so to speak.

-- 
Chris Hoess
Received on Fri Jun 18 2004 - 05:04:24 CEST

Original text of this message