Re: Honesty vs Opinion vs The Truth - Best IBM i Tool Set

The whole idea of the IBM i is a database is a "jack of all trades"

server. The data request can come from anywhere. RPG, Java, PHP, JSP,
Ruby, web service, bluetooth, punch card...

it's unrealistic for 99% of shops with existing infrastructure.

I was hoping someone would call me out because I do agree what I said is
not normal and could be viewed as "silly" or "crazy". Let me digress.

We all remember the days where a single RPG developer could manage an
entire portion of an application (i.e. order entry, inventory, shipping)
because the finite human-knowledge-capacity was based on business logic and
not technology. Then the GUI hit and we find existing RPG programmers have
reached their finite capacity not because of business logic but because
there is so much stinking technology. It was necessary to include two or
more people to facilitate furthering the GUI application because there was
just so much to learn and the unfortunate part is that usually it was
because a different language was used (i.e. C#.NET). If the GUI app would
have been kept entirely in RPG then the problem may not have been as
significant (though Javascript/HTML/CSS still needs to be learned).

That's how businesses got ahead in the 2002 - 2012 timeframe - just apply
as much technology silos as possible to be ahead of the competition. Now
everybody has technology silos so that's no longer a competitive
advantage. Instead the next competitive advantage (prediction) will be
simplifying architecture of "black box" apps and that includes the
lessening of involved languages or sources of who can directly access the
database.

FWIW, I've done this with an existing business a few years ago. It was not
cheap to remove technology silos, but the business couldn't grow with all
of the human processes involved and they were stuck with the decision of
automating the connection of the silos or creating a new app with new
design requirements that would keep them from having to hire addtl staff
for busy work.

I also need to be very careful not to paint with too broad of brush because
every situation is unique. The more we learn about Rob's situation the
better we can give input.

Further, sometimes we architect solutions with rigid rules. For example,
one could say "every table needs an RPG DB trigger since that is our new
direction", but what if instead you only did RPG DB triggers where you had
multiple systems writing to that particular table.

Never before has there been such a dire need for solid IT managers that can
gather developer/user input and make good business decisions that will make
or break the entire business. As a consumer I, in large part, pick who I
do business with based on their technology (my bank, contractors, shopping
online, internet providers, etc) and whether it saves me time.



Aaron Bartell
litmis.com - Services for open source on IBM i


On Wed, Nov 4, 2015 at 10:29 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

<Rob>I am most interested in what gives me the best bang for the long

term.

My take...

Triggers obviously will catch anything and everything. This can be a

good

thing depending on whether you have issues with many apps all doing
INSERT/UPDATE/DELETE actions against the same table. It also has the

more

complicated infrastructure (two languages, two environments (PASE/ILE),
more complicated debugging, more complicated deployment, etc). If you

have

A LOT of applications inserting/updating that you don't have control over
then this can be a good approach and worth the pain. If you do NOT have

a

lot of apps inserting/updating then this approach is overkill (IMO) and

can

instead be organized in your PHP code.

Even 10yrs down the road you can make it so rows are only inserted via a
REST call to PHP. If you have apps that are doing so much inserting that
they need crazy performance and the REST PHP is too slow then you need to
ask yourself why that other application isn't written in PHP (assuming it
is in-house).

I guess at the end of the day I am just not sold on the "RPG in the DB"
approach because it slows things down so much (aka missed deadlines).

Aaron Bartell
litmis.com - Services for open source on IBM i

Aaron,

Am I understanding that you're promoting the idea of limiting updating
tables (insert, update, delete) to only a REST call to a PHP app (proxy) as
a BETTER solution to putting all business rules at the DB level using
triggers?

We can never assume when or where a table update will come from or expect
to "control" it. The whole idea of the IBM i is a database is a "jack of
all trades" server. The data request can come from anywhere. RPG, Java,
PHP, JSP, Ruby, web service, bluetooth, punch card....

Now, while I think agree that the trigger solution would work if
implemented properly, it's unrealistic for 99% of shops with existing
infrastructure.

But, I think the idea of even suggesting you should limit DB updates to
just one "pipe"... well, I'll say it... dag nabbit... unconstitutional. :)
You can't "make it so rows are only inserted via a REST call to PHP".

Brad
www.bvstools.com
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.