The Softvelocity Memory driver is a new
file driver technology that does not use physical tables for working with data.
This is due to a RAM-based technology known as IMDD (In-Memory Database Driver).
All data is stored in Random Access Memory (RAM), which gives the driver a
number of unique properties. The driver is combined with a powerful template and
class. The template completely automates the use of In-memory tables.
When you use the "In-Memory Data Caching Support" extension template,
the Memory table doesn't even need to be defined in your Data Dictionary. You
just select the table or tables that you want cached into "memory tables," and
the template generates a FILE declaration that matches the physical file,
generates the code to cache the physical file into the memory file, and
magically replaces the use of the physical table with the cached memory table.
The beauty of the implementation is that you can choose to make any table cached
with just a couple of mouse clicks, re-compile, and immediately see the results.
You don't have to re-create the procedure, or change any code at all. Another
benefit is that you never have to worry about keeping the tables definitions
synchronized. Add a new column or Key to the physical file, and the In-memory
file definition is automatically matched.
The In-Memory driver has proven
a very easy way to speed up the most data intensive areas of your applications.
With the release of version 2, making use of cached tables is as easy as
dropping in a template and filling in a few prompts.
Characteristics of the driver:
» Extremely high performance. Once data is loaded into the MEMORY table,
either at program startup or on-demand, all access is virtually
instantaneous.
» You are also only limited by your machines memory
capacity, and because you can use VIEWs to populate MEMORY tables, and can
create VIEWs across multiple MEMORY tables, you have the capacity of storing and
working with significant amounts of hierarchical data.
» The MEMORY
driver has a standard file driver interface, so you can use Memory tables with
any Clarion entity or template that works with files (Browse, FileDrop, Report,
etc.), Including any 3rd party template!
» The application developer can
choose to locate highly dynamic or frequently referenced tables in memory, while
leaving the less intensively used parts of the database to be stored on much
cheaper disk.
» Provides highly exclusive data access. Storing data in a
MEMORY table you can be sure of its security and privacy. Even two programs
simultaneously running on the same computer will each use their own data copy.
» It's especially useful for WEB-enabled applications. In addition all
stored data will be automatically be destroyed when application terminates and
you will never have any undeleted temporary files.
» As MEMORY files are
recreated each time an application runs, you don't need to convert MEMORY tables
after a change to the record structure of your physical file.
» Can be
used as a "Global" lookup table, but unlike a global queue, you do not have to
write code to synchronize threaded access, because synchronization is built into
the driver.
» Instantaneous access to data, even when changing the sort
order or applying filters.
» Like an ALIAS structure, the MEMORY driver
can emulate the structure of any defined file in the dictionary, but unlike the
ALIAS, it can be modified with additional columns and indexes without the need
for conversion.
» You use standard file processing statements with a
MEMORY file as you would with other file formats.
Here are just some possible
tasks for the MEMORY driver.
» Use it as a Temporary table for
Parent-Child relations where the end user makes all changes to the Child in the
Memory table. For example new order items can be added and updated, and only
when the invoice is actually saved, write all the child records to the physical
file in a single transaction along with the order record.
» Use it as a
buffer for receiving SQL query results. After you have received the result set
into the Memory table you can do sorting, filtering, perform QBE/QBF requests
using standard browse box tools, without any additional access to the SQL
server. This approach can dramatically reduce network traffic and frees server
resources as fast as possible.
» Using the MEMORY driver allows you to
minimize the number of KEY and INDEX files in your physical tables. For example
if you have a rarely requested report that requires a special index you can
declare this index in the MEMORY table but not in the physical table. This way
you can reduce required database resources and speed up data I/O
operations.
» You can reduce key and index number in your physical tables
and also eliminate the need for file conversions. When you need to add a new key
or index for a Report or Browse. Just add the new INDEX to the MEMORY
table.
» You can construct your Memory table using several data sources,
and the sources can combine data tables of various formats. For example, you can
load configuration data from a mainframe file and combine it with additional
items from a local file.
Get more details here
