Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: One Ring to Bind Them

Re: One Ring to Bind Them

From: Bill H <wphaskett_at_THISISMUNGEDatt.net>
Date: Wed, 16 Jun 2004 09:54:51 -0700
Message-ID: <40d07bda$1_7@corp.newsgroups.com>


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.

There is a huge disjoint here that encourages this ongoing debate. Many MV developers work with other RDBMS products too. They're exposed to two different environments and don't like the inefficiency of the RDM that requires decomposition of business objects into a language that is not understandable. This creates uncertainty, additional cost, and additional instability. On a limited budget this is generally unacceptable.

On the other hand, there are good reasons, from my perspective, to use the RDM. Tools, ease of programming, rich graphical environment, decomposition and recomposition that's completely hidden (the black box syndrome).

> > 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
>
> A valid criticism. I could chalk much of that up to the
operationally-minded
> education of most programmers ("we're going to teach you to program just
> like a compiler writes machine code!"), but it is true that it's harder
> initially. I just think it would pay off, and that the learning curve,
while
> somewhat steep, has dividends (and not just in the long term; perhaps in
the
> "medium" range).

I program in several procedural languages, enhanced BASIC, Javascript, HTML, VB and as little C{whatever} as I can. BASIC is by far the easiest and the one everyone I work with can read and understand. However, it is not the most useful in each circumstance.

It can always be said that we can learn a new language. But what does it bring to the table? Is it worth it? English is the most useful language in the world because it is the primary language of international business. This says nothing about its usefulness locally in Germany, Egypt, China, etc (which is minimal).

> > 4) Invariably functions become one of the things to get specified. If
we
> > are going to specify both data and functions, which, afterall, is what
> needs
> > to happen,
>
> But I draw a distinction between specifying a function and implementing it
> operationally. I can code a function in Java (even though I have to attach
> it to a class), but contrast that with any algebraic specification of a
> function; maybe something like Prolog, where you are simply defining terms
> using input patterns (pardon the gross oversimplification). True, you may
> have to optimize later; but you don't have to decide on the optimization
(or
> on a sub-optimal algorithm) early.

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 think this is the largest misunderstanding in this thread. We're talking past each other when the RDM and the MVM are compared. The MVM includes, as I noted before, both an application server and development environment. The RDM is more constrained by design.

> > then what benefit is there to specifying a function and
> > specifying where it is to be used rather than specifying the function
and
> > then using it where it needs to be used?
>
> I'm not sure what you mean here. If you're arguing for the separation of
> data and function, I tend to agree; however, that's a very non-OO position
> to take... is that what you intended?

Again, we're talking past each other. The MVM includes the application server so I think this explains why some think it appropriate to include functions in the database, because the function call is stored in the database.

Bill

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =----- Received on Wed Jun 16 2004 - 11:54:51 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US