Galen Boyer wrote:
> On Tue, 28 Mar 2006, dillon_at_SpamMinuSaccessdenied.darktech.org wrote:
> > Hi,
> >
> > What is the norm when a front-end programmer (e.g VB) designs an
> > interface for a database (e.g Oracle)?
> >
> > Specifically, I mean should the front-end programmer hard-code
> > constraints like null/nullable fields into his/her interface, or
> > should he/she just output the meaningless Oracle errors to the user?
> > (e.g via the VB interface).
> >
> > I was thinking there are good and bad things about the front-end
> > programmer hard-coding/duplicating the "controls" into their program.
> >
> > The bad: if the DBA un-nulls a field on the Oracle DB, the front-end
> > will still insist on a input of data for that field. The DBA must tell
> > the programmer to do some re-coding and re-compile the front-end.
> >
> > The Good: if certain fields need to be unnulled (e.g for some
> > data-migration), it will not affect the front-end. That means
> > data-entry staff can continue to data-entry and all the "checks" will
> > still in be place.
> >
> > So what is the norm?
>
> It should be in both places really. The database design will protect
> the integrity of the data, but the software should understand the
> constraints of the database and be proactive instead of getting errors
> from constraints and react. A nice way for the front-end to accomplish
> this is to define the constraints in the application at compile-time by
> reading the database's meta-data.
>
> --
> Galen Boyer
Exactly. Not that I know anything about front-end development tools but
I would hope that Hibernate and the like would support this sort of
thing.
Received on Thu Mar 30 2006 - 09:56:47 CST
