Re: One Ring to Bind Them
Date: Wed, 16 Jun 2004 09:54:51 -0700
Message-ID: <40d07bda$1_7_at_corp.newsgroups.com>
Eric:
"Eric Kaun" <ekaun_at_yahoo.com> wrote in message
news:h2Zzc.1822$Pt.1440_at_newssvr19.news.prodigy.com...
[snipped]
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?
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).
> > 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.
> > 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 - 18:54:51 CEST