If our IBM i servers are primarily database servers, then do we want to
make data-centric development with DB2 a top priority on our IBM i servers?
What would this actually mean? And would it have any implications for the
.NET web and mobile apps that access our IBM i servers?


Regarding data-centric development on IBM i, let's define that as "code"
written and deployed on IBM i which runs queries, returns result sets,
performs data validations, implements business rules which ensure the
security and integrity of the data, and performs other operations which are
incidental to database updates, which may include such operations as
sending email and communicating with other back-end systems.

With respect to queries, there may be some debate about whether to code
them "in applications". But with respect to data validations and business
rules which ensure the security and integrity of data, I would suggest that
anyone advocating moving that code into applications would be doing a grave
disservice to the company. I doubt whether you would get much argument from
your .Net teams about that being a sound architectural premise.

If your data were stored in MS SQL Server or Oracle databases, the same
premise would apply. Code pertaining to data validation, integrity, and
security belongs on the database server. And if you place the code in or
"behind" triggers, it ensures that it can't be bypassed or overridden by
internal or external hacking - whether the hacking is benevolent or
malicious or not.

This is a good discussion to have, because there has been a lot of code
deployed "in applications" which implement data validation and business
rules. That type of code should be moved back "into the database". And if
there is resistance to that, it should be overcome. Lines should be drawn.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].