Another Database on My i? Whatever For?
What we think about MySQL
The title of this article was our reaction when we heard MySQL was coming to IBM i. Actually, our reaction was much more strongly worded—we cleaned it up for publication! The DB2 database on our system is so robust, so integrated, so simple—why on earth would anyone ever want to put another database management system (DBMS) on this platform?
After getting more detail, we’ve now become fans of the idea and we'd like to share the reasons why. For those whose horizons may not yet have expanded beyond the more traditional RPG/COBOL/DB2 realm of applications, MySQL is one of the most popular DBMSs today. And it's open source (as in free, at least in one of its incarnations). Perhaps to a great extent because of that fact, MySQL has been embraced by developers in many environments—especially those programming in languages that are themselves widely used to develop open-source applications, such as PHP and Java.
So what does this mean to us on the world's best business application platform, largely due to the power and flexibility of our particular flavor of DB2? It means access to a whole new world of applications. Remember the AS/400—as in "Application System"—was so named because of the large number of application solutions available for it? We may have moved away from the name AS/400 (at least some of us have), but the need for an easy-to-manage application platform hasn’t changed. Now, there’s whole new world of application availability—some for fee, many for free—and they’re more easily available to our platform thanks to MySQL on the i.
Some of you may be thinking, "Yes, but implementing another completely different database sounds difficult and it would surely be a nightmare to integrate data from that system into my other applications on IBM i." But what if it weren’t difficult to implement? And what if you could integrate the MySQL databases with RPG/COBOL/DB2 and/or your favorite reporting tools by simply accessing the same data using all your familiar interfaces, such as READ, CHAIN, UPDATE or with embedded SQL?
Could such a thing happen? How could the same data be accessible with completely different kinds of interfaces? It shouldn’t be that surprising if you remember DB2 has the unique flexibility of having two completely different types of interfaces: the native programming language operations originally designed for non-relational "flat file" access and relational database access via SQL.
In the case of MySQL, the integration potential was helped along by a rare feature of this database—the concept of supporting multiple "storage engines" for the data that’s managed by MySQL. With any implementation of MySQL, on any platform, you have your choice of several ways to store the data—different storage engines—each of which has its unique strengths and weaknesses in specific application scenarios. One could even write an application using MySQL that utilizes different storage engines for different tables. It's an interesting and powerful flexibility option that has much merit, especially for a DBMS that’s supported on so many different types of operating systems and application environments.
The IBM i implementation of MySQL also has a choice of several different storage engines, including the intriguing option of using DB2 for i as a MySQL storage engine. This means that a PHP or Java application using MySQL can create and manipulate data that resides in the DB2 for i database (e.g., physical file/table objects in libraries/schemas that our RPG or COBOL programs and our favorite i-based report writing tools can also access).
Search our new 2013 Buyer's Guide.
Web Exclusive | Rational enables development in multiplatform environments
Web Exclusive | Stretching the native Droid APIs for IBM i
E-Newsletter | Could cloud computing save you money?