From the Inside September/October 2012

The future has caught up with the power of MultiValue Applications, but have your MultiValue Applications caught up to the future?

We all know the power of the MultiValue data model, as well as the power of the enhanced stored procedure (Basic, I-Types, and Dictionary Correlatives) abilities MultiValue Databases provide. But have you compared what them to what the "Future Database" contains or expect to contain?

The Past Database:

  • Structured Data
  • Summarized Data

The Present Database:

  • Analytical Reporting
  • Detail Transactions instead of Summarized Data

The Future Database:

  • Massive Data
  • Enhanced Decision Reporting and Alerts In the Database
  • Hybrid Relationships (Complex Data)
  • Data Any Place
  • Massive Data

What truly is "Massive Data?" It is 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?

Hybrid Relationships

Hybrid relationships are designed to correlate structured data with the unstructured data. We all know that not all data can be placed into well-defined structures. This is either because the structure is constantly changing, or because to make it structured would require too many files, tables, accounts, and relationships to make it feasible.

Data Any Place

Most people would define this as distributed data, but in reality, all people want is to access the data from any place, anywhere, and from anything they have in front of them. The current buzz term for this is "Cloud Computing" or "Cloud Databases."

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

Enhanced Decision Reporting and Alerts

Originally, databases were set up to store and retrieve data. Nothing more, nothing less. Most applications are designed to use the database for that purpose. But a trend in database architecture is to start providing more advanced featured in the stored procedure languages to answer complex questions.

In the past, this was only available to the programmer on the client application. It required the client application to access massive amount of data, which caused the process to be slow.

Now databases are beginning to take on even more complex stored procedure logic. For example, Oracle touts the ability to create stored procedures in Java and Microsoft SQL provides the ability to include .NET assemblies in their stored procedures.

Existing MultiValue Technologies

Here is what the MultiValue data model and technologies provide that are just now emerging in the "Future Database."

Massive Data

With the built-in compressed data format (Dynamic Arrays), MultiValue developers have been handling massive data for many years. Since we could 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 existing and past databases had to contend with.

Enhanced Decision Reporting

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

MultiValue Basic, I-Types, and Dictionary Correlatives have provided us the ability to generate reports and analytics that the "traditional" databases are just now starting to implement.

Data Any Place

While the different implementations of access our data from any place is still new to us, the development needed to create a "Data Any Place" access model is not new. MultiValue developers have been designing and creating "cloud" applications and databases for years.

The only thing that needs to be done is to add the web service, mobile device, or desktop client to access the information.

Hybrid Relationships

This is not new to us. WE have been creating data models to interact with structured and non-structured data for years. Since MultiValue files don't requires that we create a dictionary to store data, we are not limited to structured data models. But if we want to implement a partial structure within a non-structured file then we can using Virtual Dictionaries (I-Types and Correlatives).

Add to this the fact that we don't have to store our data as 2-dimensional data, we can create complex relationships without the complexity of multiple structured files.

So the 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. is

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:

Sep/Oct 2012

menu
menu