Re: dataformatting in nodeJS SQL interface with IBM db2a

I've seen people argue that CPU cycles on DB servers are incredibly precious, and work should be offloaded when possible.

It's also possible that they take the a similar view as Henrik. The JS guys control the client and can make changes there. All of the various DB providers are beyond their direct control.




-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Monday, March 26, 2018 12:10 PM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] dataformatting in nodeJS SQL interface with IBM db2a

It's an eye opener for me to read that developers would just as soon implement blank trimming in a JavaScript client as opposed to implementing it in the database "layer", so to speak. To me, this is the kind of functionality that belongs "in the database" as opposed to "in the application". So that no matter which client (browser, Node.js, PHP, Ruby, Java, Python, .Net, whatever), they all are provided the same functionality.

In the database layer, people could create an SQL view that automatically trimmed trailing blanks. Or IBM could provide a connection option as suggested by Niels. But I'm ambivalent to those ideas because I have never been in favor of providing generic SQL and program call interfaces to clients, primary due to security concerns.

I favor providing granular web service APIs to clients.

The majority of security services offered by vendors in the IBM i space are designed to address concerns that are derived from shops that are providing open pathways to IBM i data and programs. In contrast, my company doesn't run any host servers on IBM i in our production environment. We don't open any ports on our firewall for those types of interfaces. That may seem pedantic to some people. But it gives me some peace of mind just knowing that those interfaces are simply not provided.