From the Inside March/April 2015

The future is catching up with the power of MultiValue Applications, but are your MultiValue Applications catching up to the future?

We all know the power of the MultiValue data model. We also know the power of the Enhanced Stored Procedure abilities included with MultiValue Databases: BASIC, I-Types, and Dictionary Correlatives. But have you compared them to what your company is expecting of their datastore?

Challenge: Massive Data

What is Massive Data? Is it the size of the overall database or the number of transactions in any one file? Or is it the number of transactions consumed in a minute, hour, or day?

Challenge: Enhanced Decision Reporting and Alerts

Originally, databases were set up to store and retrieve data; nothing more, nothing less. Most applications are still designed to use the database for that purpose. But the emerging trend in database architecture is to start providing more advanced features in the stored procedure languages to provide answers to complex questions.

In the past, this approach was only available to the programmer who created the client application. And it required the client application to access massive amount of data, causing the process to be slow.

Nowadays, databases are beginning to take on even more complex logic. Oracle 10i touts the ability to write database procedures in Java. Microsoft SQL Server and PostgreSQL both support the use of Perl, Python, and PL/R for writing database functions.

Challenge: Hybrid Relationships

Hybrid Relationships are a method for correlating structured data with unstructured data. Not all data can be placed into well-defined structures. This is either because the structure is constantly changing, or because making it structured would require too many files, tables, accounts, and relationships to make it feasible.

Challenge: Data Any Place

Most people would define this as distributed data. People want to access the same data from any place, anywhere, using any device they have in front of them. The current buzz-term for this is "Cloud Computing" or "Cloud Databases".

While each of these technologies are implemented to address a specific issue, the real issues they are trying to address are "Ease of Access" and "Deployment of Changes."

Here is what the MultiValue databases are providing to address these needs.

Challenge Accepted: Massive Data

Thanks to the built-in compressed data format (Dynamic Arrays), MultiValue developers have been handling massive data for many years. Since we could always store large amounts of data and transactions in less space on the physical disk, we have never had to address the processing power and cost of storage issues that competing databases contend with. We're good with Massive Data as-is.

Challenge Accepted: Enhanced Decision Report and Alerts

We have always been sever-centric developers. Because of this, most of our programming, processing, and reporting have been done on the database servers, instead of offloading the data to the client.

MultiValue BASIC, I-Types, and Dictionary Correlatives provided us the ability to generate reports and analytics that the "traditional" databases are just now starting to implement. We have the tools to address Enhanced Decision Report challenges.

Challenge Accepted: Hybrid Relationships

This is not new to us. We have been creating data models which interact with structured and non-structured data for years. Since MultiValue files don't require a strict schema or dictionary in order to store data, we are not limited to structured data models. If we want to implement a partial structure within a non-structured file, we are able to do so using Virtual Dictionaries (I-Types and Correlatives).

Additionally, we don't have to store our data as two-dimensional data. We can create complex relationships without the complexity of a multiple file structure. MultiValue has always supported Hybrid Relationships .

Challenge Accepted: Data Any Place

While there is an ever-growing list of "Any Places," the need to create a Data Any Place access model is not new. MultiValue developers have been designing and creating "Cloud" applications and databases for years.

While the receiving applications still need to be built, attaching them is often as simple as building a web service. We have those tools on nearly every MultiValue platform; either built-in or with the help of readily-available third party tools.

So, next time you have a conversation with management about what a MultiValue database is or is not capable of, take a moment to think about what I've outlined here and say "Challenge Accepted."

Nathan Rector

Nathan Rector, President of International Spectrum, has been in the MultiValue marketplace as a consultant, author, and presenter since 1992. As a consultant, Nathan specialized in integrating MultiValue applications with other devices and non-MultiValue data, structures, and applications into existing MultiValue databases. During that time, Nathan worked with PDA, Mobile Device, Handheld scanners, POS, and other manufacturing and distribution interfaces.

In 2006, Nathan purchased International Spectrum Magazine and Conference and has been working with the MultiValue Community to expand its reach into current technologies and markets. During this time he has been providing mentorship training to people converting Console Applications (Green Screen/Text Driven) to GUI (Graphical User Interfaces), Mobile, and Web. He has also been working with new developers to the MultiValue Marketplace to train them in how MultiValue works and acts, as well as how it differs from the traditional Relational Database Model (SQL).

View more articles

Featured:

Mar/Apr 2015

menu
menu