HP3000-L Archives

March 2001, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mark Boyd <[log in to unmask]>
Reply To:
Mark Boyd <[log in to unmask]>
Date:
Wed, 7 Mar 2001 10:02:07 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (71 lines)
These are functions of a data entry application, NOT a dbms.

"Input masking, value limits, non-structural data
validation"

-----Original Message-----
From: James B. Byrne [mailto:[log in to unmask]]
Sent: Wednesday, March 07, 2001 9:38 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Expensive RDBM Systems (Oracle)

On 6 Mar 2001, at 13:40, Wirt Atmar wrote:

> What features do see lacking in IMAGE?
>

Input masking, value limits, triggers, non-structural data
validation, field overlays, composite key fields, and a few others
that I can't bring to mind.   Admittedly most if not all of these can
be designed around or dealt with satisfactorily by a good data-
dictionary based programming environment like Powerhouse, or
Transact, or Speedware.  However, choosing one of these products sort
of limits your programming options.

> So far, I haven't found anything I can't do in IMAGE -- at greater
> efficiency and with less cost (both in development time and real
> dollar maintenance) than I can in any RDBMS.
>

Absolutely correct, and as far as I see this will always be the case.
However you and I are fairly limited resources and have more than a
modicum of experience with the product.  We also have the luxury of
being able to insist on our standards of design and programming.
Corporate programming is, and always has been, filled with mediocre
programmers working on poorly formulated projects with indifferent
design standards.  These people need more structure and control
enforced where the database designer can place it and not simply
dependent on administrative procedures to catch problems.

Controlling large projects or multiple projects can become more of a
programming issue when using Image simply because Image does not
enforce non-structural data validation rules below the application
program level.  Adding a bunch of junior programmers with limited
data-base experience, a project lead with little more, and an over-
worked designer who might or might not be available, usually results
a lot of avoidable development work.

Maintenance is also a little harder when the data-base doesn't reveal
all of its little idiosyncrasies to the person or team tasked with
adding a new feature or subsytem to an existing application.

Frequently the solution is to add one of the afore-mentioned data-
dictionary products or something similar. This is obviously a non-
integrated answer and  brings with it its own learning curve and
limitations, not to mention expense.  Even then this still doesn't
speak to the problem of programs modifying the data outside of the
dictionary restraints.

I love Image but there are a number of things still missing from it
that CinCom's Total had in 1981.  On the other hand, being able to
design a well structured Image database makes working with MS-SQL 7 a
breeze.

Regards,
Jim
---   *** e-mail is not a secure channel ***
James B. Byrne                Harte & Lyne Limited
vox: +1 905 561 1241          9 Brockley Drive
fax: +1 905 561 0757          Hamilton, Ontario
mailto:[log in to unmask]  Canada L8E 3C3

ATOM RSS1 RSS2