Thank you for your responses.  They are extremely valued by me.

On Wed, 17 Aug 2005 12:13:20 -0400  Mark Wonsil <[log in to unmask]> wrote:

> The question one might ask is why will this be a very, very long
> process?

Because things are never as one imagines. It might be long, it might
be short, but experience informs my belief that the path more often
takes longer than shorter than first imagined.

In the case in point we have been visiting this issue on the and off
since early 2002 .  That is the already three and one-half years. The
system we are converting was built in stages over a period of eight
years beginning in 1984. Later portions reflect the considerable
changes in business practice wrought by the high degree of
technological change experience during that period.  The system was
also designed specifically for Image and Powerhouse, taking into
account the strengths and limitations of those two technologies and
the processing restrictions of its original host, an HP3000 series
37.

The present design and implementation therefore possess several
(judicious) deviations from standard practises with respect to data
normalization and data representation reflecting compromises made to
accommodate these limits.  Obviously these factors are no longer a
consideration, but there are similar choices facing us with respect
to Linux, PostgreSQl and Ruby and we are not as well versed with
limits and capabilities of the new as we feel we are with the old.
So I am being conservative (I hope) in my expectations.

The replacement system is being redesigned to bring the earlier
portions for the existing system into line with the later ones and to
upgrade the entire edifice with respect to present day practice.  We
are budgeting 36 calendar months for this project (commencing now)
and we expect to have the early modules available for user testing
possibly as early as October this year.  However soon that might
appear to some, from my perspective that remains a long way from a
finished, integrated replacement.  It will in any case no doubt seem
a long time regardless of how short it is temporally.

Perhaps my view of the world has been jaded by too many brushes with
disasters masquerading as IT projects but I find the public debate
over MVC concepts, both by expert and non-expert alike, somewhat
confusing and often plain misleading.  For example I read an article
in a reputable on line journal devoted to IT design issues wherein
the featured columnist took as their example of improper design
concepts involving the MVC paradigm the telephone number.

Describing the various formats that telephone numbers are
conventionally displayed throughout the world they discussed where,
in an MVC system, the number format should be processed.  Their
argument was as this was a display issue then it belonged in the
view, and as the storage format was a business logic issue then the
store format belonged in the business logic and, as their design
philosophy held that data store management software should only deal
with Create, Retrieve, Update, and Delete (CRUD) actions, the
telephone number should not have any SQL formatting statements at the
DBMS level at all.

I found this argument unconvincing, skewed by an apparently
unreflective and simplistic design philosophy driven perhaps by
experience with the high degree of variability in the capabilities of
various DBMS.

From my perspective the DBMS is the fundamental material from which
the system is built. The choice selected may be akin to titanium
alloy or to balsa wood but, whatever its virtues or limits may be, it
becomes the material with which the skeleton of the system is made
and from which the flesh of the applications will hang.  I see no
point in insisting that design philosophies consider flesh as
requiring sufficient rigidity to compensate for a weak skeleton any
more than they should demand skeletons sufficiently flexible to cover
areas where flesh will not go.  One is condemned by ones choice of
data store to certain architectural approaches just as the choice of
steel over pine shapes the structure of a bridge.

To me, while the presentation of a telephone number is undoubtedly
the function of the view, the store format of the number string
itself belongs, as much as is possible, at the DBMS level.  If an
application passes a string like "+1 (900) 555-4731" or "1 900 555
4731" or "+1 900-555-4731" to the DBMS then I think that it is
entirely reasonable that a stored procedure should be able to
transform any of them into 19005554731 and stuff it into the data
field without further ado. it should also check for length and refuse
non-numerical data such as "+1 900 310-BELL", unless of course the
many to one mapping of Roman letters to digits is accepted as a
business rule.

If the application programmer feels differently then there is nothing
stopping them from doing this themselves in their controller and then
passing flat numerical strings to the DBMS, but why should each and
every user field dealing with phone numbers in the model require the
same functionality be repeated over and over again in various
controllers?  What happens when somebody forgets or is ignorant of
the need? How much needless and avoidable work and delay does forcing
users to discover the "right" format of a telephone number for this
particular entry application create?

Maybe I am missing something fundamental here but I cannot see that
the DBMS necessarily should be separate from the controller, except
in the case of judicious choices made to accommodate environmentally
specific limitations.  Indeed, from a logical viewpoint, the DBMS
seems to me a fundamental part of the controller component since it,
and it alone, provides access to the model.  All other controllers
are of their very nature decorations of this essential
characteristic.

However, if I am mistaken my estimation then I welcome correction.

Regards,
Jim

--

***     e-mail is NOT a secure channel     ***
James B. Byrne                mailto:ByrneJB.<token>@Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3CE               delivery <token> = hal

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *