Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: topmind <>
Date: 17 Jun 2006 18:09:07 -0700
Message-ID: <>

David Cressey wrote:
> "topmind" <> wrote in message
> >
> > To be fair, I think R. Martin tends to focus on industries where
> > reliability and testability are more important than being nimble. Extra
> > layers for e-beurocracy between the DB and app code perhaps make it
> > easier to test stuff in isolatable pieces perhaps and have like a
> > sign-off sheet and official tests for each part.
> >
> > Most companies do not want to spend the money on such stuff and thus
> > are happy with thin layers betweens between the app and the DB.
> > Further, it may make most changes easier since there is less middle-man
> > code between the DB and app to also change.
> >
> > I cannot be sure this is what R. Martin focuses on, but the nature of
> > his writing implies such. I can see the need for more formal separation
> > in say the medical industry where companies can get sued for hundreds
> > of millions if a device goes wrong and they need to hunt down the
> > organization or person involved to punish and sue, like we love to do
> > as a nation.
> >
> > -T-
> >
> I've been following this debate, and I have a slightly different take on
> what R. Martin is talking about.
> Most of R. Martin's recent posts in this discussion have been directed to
> the *internal* structure of the application. The whole question of whether
> it's better to sprinkle SQL all over the place in the application, or
> collect it one module, is moot if your point of view is external to the
> application. That's my point of view.
> Don't get me wrong. The point is worth discussing. But it's only worth
> discussing in the context of individual application design, development, and
> maintenance.
> If you look at things from a coarser level of granularity,
> the DB and the DBMS that serves it up are both replaceable parts. You'd
> like to be able to swap it out, and swap in a new one without the "ripple
> efect" swamping all the existing applications in a huge maintenance effort.
> But (and this is a big but) from this level of granularity, each
> application in the collection is *also* a replaceable part. You'd like to
> be able to swap out any application, and replace it with a new one that
> provides data to the DB without having the "ripple effect" propagate to all
> the other applications that use the same DB.
> Modularity and encapsulation help control the ripple effect within an
> application. Within a collection of applications that all treat the same DB
> as a data nexus, data independence is the best way to control the ripple
> effect.
> The problem with application developers is that they tend to fall into the
> trap that says that their application is the center of the universe. The
> problem with database designers and DBAs is that we tend to fall into the
> opposite trap. We tend to think of our database as the center of the
> universe.
> I suspect that there is a third trap, one that network people tend to fall
> into. But I don't have enough experience to describe it.
> Strategic data planners need to avoid all three traps.

If this was true, then it seems everybody would want swappability because it would allow them to keep their part without worrying about the other parts/groups. Everybody would want to easily find and keep their part regardless of what happens to the other parts/groups' stuff.

But aside from which is the true nexis, there is the issue of the cost of separation. Separation is not free regardless of why it is done. It creates interface red-tape between the parts, and maintaining those interfaces is usually more time consuming than if they were not there to be begin with.

Further, the frequency of the need to swap is not that high. DB vendors don't go out of business often enough to justify the cost of isolation up-front, for example. RCM exaggerates that boogie man in my opinion. If I coded every What-If scenario I could dream up, "Hello World" would be a thousand lines

  if (inSpace) {
    msg = "Hello Drifters"
  } else {
    msg = "Hello World"
  if (printer.isBroken()) {
  } else {

Plus, it is not that hard to search for SQL statements in code. Maybe in the future code will be stored in databases instead of files such that one can view a given task or segments along with the SQL or group it by just app code or just SQL, etc. We need the ability to query the source code to give us any damned view we please instead of that forced on us by the original file structure or by Bill Gates. File systems are the real cultprit here, forcing the either-or grouping/view of SQL on us.

-T- Received on Sun Jun 18 2006 - 03:09:07 CEST

Original text of this message