Re: One Ring to Bind Them

"Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message news:bcb8c360.0406180909.7fe81c07_at_posting.google.com...
> > "Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message
news:<40d07bda$1_7_at_corp.newsgroups.com>...
> >
> > 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).

Why would you think these same issues are less in a client/server model? If the rules are kept in the client application they're spread out everywhere and are far more difficult to update and maintain. In addition, in the client world there are a lot more kinds of languages de'jour available to cause this very difficulty you've identified.

If the application were moved to an application server this eliminates a lot of issues present in a client/server model. If, however, a dbms included an application server the application would, by definition, be included in the database. So, I think your comments, although proper for a RD model are not so for other models.

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

You can paraphrase if you'd like. :-) I would, however, note that I specifically stated the RD model is perfectly useful at times. I don't agree it is useful at _all_ times and I think there are perfectly useful and adequate alternatives that don't adhere to relational axioms. I just happen to think it is useful to keep things as simple as possible and decomposition/recomposition creates complexity and, for me anyway, confusion. I am not, unfortunately, a rocket scientist and a business mogul all in one.

> > 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" ?

Lawyers see the world through legalistic terms...everything seems to be a legal conflict resolvable via dispute resolution. I tend to appreciate a broader perspective (even though I suffer from the same human condition). The tools and other "...nice bits and bobs..." aren't associated with the RD model (they aren't part of it).

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

I prefer a more flexible view of the world. I not looking for the next "Theory of Relativity". :-) I'm simply looking for more clarity and ease of use.

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

And there you have some points to bring to the collective table. :-)

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

It is important if that's the structure or rules under which we're operating. If, on the other hand, a model exists where the functions are both dbms and user defined this has some advantages too. Of course the dbms functions are application independent but more functions should be able to be added.

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

They are implementation decisions if is is defined as such. Some dbms products are also application servers, so there is no such decision to make (except with the purchase). This makes web development pretty simple but client/server development using SQL more difficult.

Bill Received on Thu Jun 24 2004 - 04:26:48 CEST