×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
One part of me agrees with you, Nathan. Even in a small shop like ours, it is hard to keep the database rules up-to-date. This may be because we migrated from a /36 and all of the business rules *had* to be in the programs so we just got used to doing it that way (not always a good reason, just an excuse).
But database constraints can be beneficial when someone tries to maintain a file or table outside of the prescribed method (e.g., an RPG program), such as DFU or an Access db. In fact, I wish that we used this more often, but retro-fitting seems to take a back seat.
Thanks.
Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, September 08, 2009 2:41 PM
To: Midrange Systems Technical Discussion
Subject: Re: Design question - layered approach
From: Terrence Enger
The more basic rules clearly should be enforced by (at least) the
database definition itself.
We kind-of got into that when Relational DBMS products first began offering that capability, but have since moved away from it, in favor of keeping business rules in RPG service programs, rather than dividing responsibility for business rules between DBAs and application developers - who don't always communicate with each other. Just to be consistent - keep rules in one place - under one responsibility.
Nathan.
midrange.com
