|
Hi Rob and Welcome!
I would echo much of the sentiment you are discovering here and go one
further. You mention using DB2 Storage Engine and MySQL as an interface.
I would guess that is because you are familiar with MySQLi. As Nathan
indicated about performance, it ain't gonna happen. There is no way an
abstraction layer can outperform native I/O and SQL. In a nutshell, IBM
has had 40 years to optimize the platform for RPG and PHP is celebrating
its 10th anniversary on the platform. Java's been here 20 years and still
can't hold a candle to RPG performance. Also, the version of MySQL
supported on IBM i is 5.1, at this moment. There is work being done on
the future versions so watch this space.
One thing I suggest you take some time to learn is DB2 for IBM i. The
extension is described here http://php.net/manual/en/book.ibm-db2.php
and while the interfaces are procedural, they can be wrapped in classes
quite easily or you could use PDO.
http://yips.idevcloud.com/wiki/index.php/PHP/DB2 Even if you use MySQL as
the interface, you'll still need to understand how the query optimizer in
DB2 is affected by index, etc. There are visual tools that help you
leverage DB2 so don't let anyone tell you that DDS is all you have!
PLEASE do not fall for that one!!!
So, if you cannot come to ZendCon, please seriously consider going to
Jon's conference, RPG & DB2 Summit
(http://systemideveloper.com/summit/conferences.html ) to learn the proper
way to work with DB2 and I think you'll see the best performance possible
for PHP (or any language) on IBM i via DB2 optimization. I'll be there on
Monday but have to skedaddle to Vegas for the Zend conference Monday
night. Paul Tuohy, Tom McKinley, Kent Milligan and Ted Holt will all be
doing sessions that apply to ANY SQL developer on IBM i and this knowledge
can take you a long way! I apologize to anyone who believes that Jon and
I are being shills for each other's events, but I assure we are sincere!
While you're there you can sit in on a session or two on RPG and learn
about some of the more modern features of the language that you might not
learn anywhere else!
Also, get thyself to more current OS levels. This is the key to the most
current version of DB2 on the platform as DB2 is "FULLY" integrated to the
operating system. There are some really great things in 7.2 and some
REALLY cool things coming down the road for recovering MySQL developers,
too! My favorite question from a MySQL developer (and I've met quite a
few) is how do I restart DB2? That is funny to all of us IBM i veterans
because the answer is you IPL or reboot the IBM i. I for one can say that
in 20+ years of development on IBM i and its predecessors, I have only had
to reboot because of the database once. And that was because of a self
inflicted problem the programmers created with 24 hours of journaling
trying to roll back.
The IBM i may look and feel like a tank, but once you take the time to
learn how to drive it, it will start to feel like a Jaguar!
I am happy to be a reference on list or off.
Regards,
Mike Pavlak
Cell: (408)679-1011 Office: (708)233-5880
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bradley
Stone
Sent: Thursday, October 01, 2015 10:38 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Elevator speech on DB2 development and web
enablement?
I couldn't agree more about XML, JSON, <whatever it is next week> as far
as transport vs storage.
The only thing I can think of why you would store in JSON vs a RDB is
because it's "hip". Wow.. that made me sound older than I am.. haha.
Brad
www.bvstools.com
On Thu, Oct 1, 2015 at 9:15 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
much.
I was referring to the technology preview regarding JSON:
https://www.ibm.com/developerworks/ibmi/library/i-json-store-technol
ogy/
That article is more about using the QSHELL command line interface,
and / or Java API for "retrieving" JSON-formatted data. But it sounds
like the storage of JSON documents in BLOB or CLOB fields hasn't changed
--
Frankly, I can't think of a good use case for "storing" JSON or XML
documents in IBM i database tables. JSON seems like a great format for
data interchange. But once the data arrives on IBM i, it seems that it
would work much better to extract the "data" from the document and
store it in normalized formats (tables, rows, columns).
So, I too would be interested in hearing about use-cases for storing
JSON documents in the database. Just to be like MongoDB? Why?
--
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.
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.