Re: One Ring to Bind Them

"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message news:<40d07bda$1_7_at_corp.newsgroups.com>...

<snip>

> ...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.
>

And I will state categorically "no". To paraphrase my friend Roy, "a database is for life - applications are for Christmas". There can't be cost advantage for many when the applications are more mobile than the data underneath, resulting in reimplementing the same logic over and over (in Cobol, or C, or J2EE, or .Net, or whatever the next fad will be). And if you have to change the constraints in the database, that either means that the business you're dealing with has changed (which is fair enough) or you missed something in your model (which isn't, really).

Could I refer you to Roy's recent presentation at CA World 2004 and the UK Ingres Users Association on Constraints for Performance ? It is quite Ingres specific, but it may provide food for thought. It's available on http://www.rationalcommerce.com/resources/constraints.htm.

> 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.
>

So, can I paraphrase as "we don't want to use relational, because we disapprove of the perceived inefficiency of implementations, and because we don't like the way relational modelling handles our data".

> 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).
>

But then, "we like the fact that there are lots of nice bits and bobs to paper over the bits we don't like" ?

> 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 is my firm (and hardening) view that the imperative model of programming, with its silly word/record at a time view of the world and reliance of fiddling with variables, is the source of the majority of the programming world's ills. I think it is simply bizarre that in the 21st century we are still being encouraged to think in terms of updatable cells of storage and simplistic kiddie steps when far higher levels of abstraction are readily available. This is one of my two main bugbears with TTM; that it rejects declarative / applicative / referentially transparent models of programming - so although it's much better in terms of handling relations, in terms of programming, operator definition etc. it's just more of the same old stuff.

> 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).
>

Hmmmmmmmm ! Depending on the language you're using, how about provability ? Executable specifications ? No more worrying about race conditions (if you don't have shared memory, how can you have race conditions ?) ? Handling logically infinte data structures ? Type inference ? Simpler programming by case analysis ?

> > > 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.
>

To reply to Eric's point in passing - or, you could simply execute the specification ... :)

> 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.
>

Side question : are these *dbms* functions, or are they operators defined on values of the date type ? There is a difference, and it *is* an important difference...

> 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.
>

Well, we have to be clear here; which functions are we talking about - operators on data types (such as the date functions mentioned above) which are independent of any given application or functions specific to some particular application ?  

> 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.
>

The inclusion of an application server and/or a development environment are implementation decisions - there's nothing in the relational data model to say you can't do the same thing in an implementation of an RDBMS if you wanted to. Necessarily RDM doesn't prescribe anything about that AS or IDE.

<snip>

Anyway, it's 6 o'clock on Friday evening - it's time to be in the pub, not writing on Google !!!

Cheers !

• Tony