home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload
/
ShartewareOverload.cdr
/
database
/
mbase.zip
/
MBASE.DOX
< prev
next >
Wrap
Text File
|
1991-02-11
|
33KB
|
401 lines
/\
/ \
../ \....METALBASE release version 3.1......................................
/ \
/ \ Written August 1989 through October 1990 by Huan-Ti
\ /
\ / Initially released December 10th 1990
\ /
\ /
\/
"And Calvin ate. And Food Lion went out of business. Amen."
--1st Calvin 4:8
WHY_METALBASE_?________________________________________________________________
The Amiga 500 multi-tasks. Wow. It has great graphics. Yeah. Phenomenal
sound. Yippee. It costs $500. I bought one.
A DBase package costs more than the computer. So does Paradox. And
Informix. And almost every other database package on the market. I didn't
buy one.
But I needed a database for my system. Anybody who's ever worked with a
database knows they're addictive--code that's written without a flexible
database backing it up lacks something. And DBase wants $600 to put that
something back into programs. No thanks.
That's why MetalBase was written... its forerunners (versions 1.0 and
2.0, not available) were designed by the same author with the Amiga line's
needs specifically in mind: relatively slow floppy drives (Compared to hard
drives), so sparse read-head maneuvering was essential. Relatively small
memory, when compared with the amounts of memory required by most C compilers
(Lattice needs roughly 300k just to run, for example), so the code had to be
consise, pure, and use few variables. Expansion was always available; hard
drives, huge memory capacities, extra processors, ram drives -- so the system
had to be readily expandible and flexible enough to meet the requirements of
both a 512k, 1-drive machine and a 4-megabyte, 120-meg hard drive-driven
setup. And they were.
The problem was, Amigas can multi-task. So what is the rest of the
computer doing while a database runs around looking up records on one drive?
Nothing. Why not let it look up records on another drive? Fine... that works.
What about on the same drive... using, say, a ram disk, so there are no real
read-heads to worry about positioning? That would mean each relation would
have to support multi-user access... a requirement around which MetalBase
versions 3.0 and 3.1 focus. Not only can many terminals access many files at
once, but on multi-terminal systems, each terminal can work simultaneously on
any given file. Terminals can each use as many relations as a system will
allow, and each relation can be used by over one hundred users at once. The
code used to create MetaBase 3.X is completely compatible with the Unix )
operating system and all of its derivatives, so its inherent multi-user
ability places it in firm working footing on the most advanced systems on the
market.
Relations are designed by a user to match his/her exact requirements,
indicies placed as needed on single or composite fields, and records can be
added, retrieved, changed, and deleted as any C programmer so desires. The
interface is as simple as possible, very fast in execution, and provides a wide
range of error types for exact specification of problems. A user on any
terminal can choose to lock out other users from any number of relations, so
data that is about to be changed will not be read by others before changes
take place. Automatic temporary locks are placed on a relation which is about
to undergo a deletion or addition, thus delaying other users' access to files,
so that no data will be read until all indicies have been updated correctly.
This process is entirely system-driven; users never need worry about it at all.
If another user is adding a record to a relation, any terminal requesting a
record lookup will simply wait until the addition is complete before
proceeding. As records are deleted and added through normal use, the algorythms
used to update indicies automatically keep them at top operating speeds, so any
given relation's number of records can grow exponentially while causing only a
linear increase in look-up time. Any relation can contain over four billion
records (Nearly four billion more than most systems will ever need), and each
record's length can be as large as its system's memory can handle. In
perspective, MetalBase is infinitely expandible, while requiring very little of
the system on which it operates.
RELATION_DESIGN________________________________________________________________
A sample relation. Data Field # -> 1 2 3 4 5
is read by selecting one Record # _____ ___ ____ ___ ___________
record from the others by 1 |_____|___|____|___|___________|
various criteria, and 2 |_____|___|____|___|___________|
returning it to the user. 3 |Smith| 12| 114| A2|Houston, TX|
Record 3 (In this example-- 4 |-----|---|----|---|-----------|
actual MetalBase records need
no such numbering system), if returned, would be placed in a string
as "Smith| 12| 114| A2|Houston, TX|"
A relation is a collection of records, each record consisting of the same
number of fields, character strings whose length remains /\
/ \
../ \....METALBASE release version 3.1......................................
/ \
/ \ Written August 1989 through October 1990 by Huan-Ti
\ /
\ / Initially released December 10th 1990
\ /
\ /
\/
"And Calvin ate. And Food Lion went out of business. Amen."
--1st Calvin 4:8
WHY_METALBASE_?________________________________________________________________
The Amiga 500 multi-tasks. Wow. It has great graphics. Yeah. Phenomenal
sound. Yippee. It costs $500. I bought one.
A DBase package costs more than the computer. So does Paradox. And
Informix. And almost every other database package on the market. I didn't
buy one.
But I needed a database for my system. Anybody who's ever worked with a
database knows they're addictive--code that's written without a flexible
database backing it up lacks something. And DBase wants $600 to put that
something back into programs. No thanks.
That's why MetalBase was written... its forerunners (versions 1.0 and
2.0, not available) were designed by the same author with the Amiga line's
needs specifically in mind: relatively slow floppy drives (Compared to hard
drives), so sparse read-head maneuvering was essential. Relatively small
memory, when compared with the amounts of memory required by most C compilers
(Lattice needs roughly 300k just to run, for example), so the code had to be
consise, pure, and use few variables. Expansion was always available; hard
drives, huge memory capacities, extra processors, ram drives -- so the system
had to be readily expandible and flexible enough to meet the requirements of
both a 512k, 1-drive machine and a 4-megabyte, 120-meg hard drive-driven
setup. And they were.
The problem was, Amigas can multi-task. So what is the rest of the
computer doing while a database runs around looking up records on one drive?
Nothing. Why not let it look up records on another drive? Fine... that works.
What about on the same drive... using, say, a ram disk, so there are no real
read-heads to worry about positioning? That would mean each relation would
have to support multi-user access... a requirement around which MetalBase
versions 3.0 and 3.1 focus. Not only can many terminals access many files at
once, but on multi-terminal systems, each terminal can work simultaneously on
any given file. Terminals can each use as many relations as a system will
allow, and each relation can be used by over one hundred users at once. The
code used to create MetaBase 3.X is completely compatible with the Unix )
operating system and all of its derivatives, so its inherent multi-user
ability places it in firm working footing on the most advanced systems on the
market.
Relations are designed by a user to match his/her exact requirements,
indicies placed as needed on single or composite fields, and records can be
added, retrieved, changed, and deleted as any C programmer so desires. The
interface is as simple as possible, very fast in execution, and provides a wide
range of error types for exact specification of problems. A user on any
terminal can choose to lock out other users from any number of relations, so
data that is about to be changed will not be read by others before changes
take place. Automatic temporary locks are placed on a relation which is about
to undergo a deletion or addition, thus delaying other users' access to files,
so that no data will be read until all indicies have been updated correctly.
This process is entirely system-driven; users never need worry about it at all.
If another user is adding a record to a relation, any terminal requesting a
record lookup will simply wait until the addition is complete before
proceeding. As records are deleted and added through normal use, the algorythms
used to update indicies automatically keep them at top operating speeds, so any
given relation's number of records can grow exponentially while causing only a
linear increase in look-up time. Any relation can contain over four billion
records (Nearly four billion more than most systems will ever need), and each
record's length can be as large as its system's memory can handle. In
perspective, MetalBase is infinitely expandible, while requiring very little of
the system on which it operates.
RELATION_DESIGN________________________________________________________________
A sample relation. Data Field # -> 1 2 3 4 5
is read by selecting one Record # _____ ___ ____ ___ ___________
record from the others by 1 |_____|___|____|___|___________|
various criteria, and 2 |_____|___|____|___|___________|
returning it to the user. 3 |Smith| 12| 114| A2|Houston, TX|
Record 3 (In this example-- 4 |-----|---|----|---|-----------|
actual MetalBase records need
no such numbering system), if returned, would be placed in a string
as "Smith| 12| 114| A2|Houston, TX|"
A relation is a collection of records, each record consisting of the same
number of fields, character strings whose length remains /\
/ \
../ \....METALBASE release version 3.1......................................
/ \
/ \ Written August 1989 through October 1990 by Huan-Ti
\ /
\ / Initially released December 10th 1990
\ /
\ /
\/
"And Calvin ate. And Food Lion went out of business. Amen."
--1st Calvin 4:8
WHY_METALBASE_?________________________________________________________________
The Amiga 500 multi-tasks. Wow. It has great graphics. Yeah. Phenomenal
sound. Yippee. It costs $500. I bought one.
A DBase package costs more than the computer. So does Paradox. And
Informix. And almost every other database package on the market. I didn't
buy one.
But I needed a database for my system. Anybody who's ever worked with a
database knows they're addictive--code that's written without a flexible
database backing it up lacks something. And DBase wants $600 to put that
something back into programs. No thanks.
That's why MetalBase was written... its forerunners (versions 1.0 and
2.0, not available) were designed by the same author with the Amiga line's
needs specifically in mind: relatively slow floppy drives (Compared to hard
drives), so sparse read-head maneuvering was essential. Relatively small
memory, when compared with the amounts of memory required by most C compilers
(Lattice needs roughly 300k just to run, for example), so the code had to be
consise, pure, and use few variables. Expansion was always available; hard
drives, huge memory capacities, extra processors, ram drives -- so the system
had to be readily expandible and flexible enough to meet the requirements of
both a 512k, 1-drive machine and a 4-megabyte, 120-meg hard drive-driven
setup. And they were.
The problem was, Amigas can multi-task. So what is the rest of the
computer doing while a database runs around looking up records on one drive?
Nothing. Why not let it look up records on another drive? Fine... that works.
What about on the same drive... using, say, a ram disk, so there are no real
read-heads to worry about positioning? That would mean each relation would
have to support multi-user access... a requirement around which MetalBase
versions 3.0 and 3.1 focus. Not only can many terminals access many files at
once, but on multi-terminal systems, each terminal can work simultaneously on
any given file. Terminals can each use as many relations as a system will
allow, and each relation can be used by over one hundred users at once. The
code used to create MetaBase 3.X is completely compatible with the Unix )
operating system and all of its derivatives, so its inherent multi-user
ability places it in firm working footing on the most advanced systems on the
market.
Relations are designed by a user to match his/her exact requirements,
indicies placed as needed on single or composite fields, and records can be
added, retrieved, changed, and deleted as any C programmer so desires. The
interface is as simple as possible, very fast in execution, and provides a wide
range of error types for exact specification of problems. A user on any
terminal can choose to lock out other users from any number of relations, so
data that is about to be changed will not be read by others before changes
take place. Automatic temporary locks are placed on a relation which is about
to undergo a deletion or addition, thus delaying other users' access to files,
so that no data will be read until all indicies have been updated correctly.
This process is entirely system-driven; users never need worry about it at all.
If another user is adding a record to a relation, any terminal requesting a
record lookup will simply wait until the addition is complete before
proceeding. As records are deleted and added through normal use, the algorythms
used to update indicies automatically keep them at top operating speeds, so any
given relation's number of records can grow exponentially while causing only a
linear increase in look-up time. Any relation can contain over four billion
records (Nearly four billion more than most systems will ever need), and each
record's length can be as large as its system's memory can handle. In
perspective, MetalBase is infinitely expandible, while requiring very little of
the system on which it operates.
RELATION_DESIGN________________________________________________________________
A sample relation. Data Field # -> 1 2 3 4 5
is read by selecting one Record # _____ ___ ____ ___ ___________
record from the others by 1 |_____|___|____|___|___________|
various criteria, and 2 |_____|___|____|___|___________|
returning it to the user. 3 |Smith| 12| 114| A2|Houston, TX|
Record 3 (In this example-- 4 |-----|---|----|---|-----------|
actual MetalBase records need
no such numbering system), if returned, would be placed in a string
as "Smith| 12| 114| A2|Houston, TX|"
A relation is a collection of records, each record consisting of the same
number of fields, character strings whose length remains /\
/ \
../ \....METALBASE release version 3.1......................................
/ \
/ \ Written August 1989 through October 1990 by Huan-Ti
\ /
\ / Initially released December 10th 1990
\ /
\ /
\/
"And Calvin ate. And Food Lion went out of business. Amen."
--1st Calvin 4:8
WHY_METALBASE_?________________________________________________________________
The Amiga 500 multi-tasks. Wow. It has great graphics. Yeah. Phenomenal
sound. Yippee. It costs $500. I bought one.
A DBase package costs more than the computer. So does Paradox. And
Informix. And almost every other database package on the market. I didn't
buy one.
But I needed a database for my system. Anybody who's ever worked with a
database knows they're addictive--code that's written without a flexible
database backing it up lacks something. And DBase wants $600 to put that
something back into programs. No thanks.
That's why MetalBase was written... its forerunners (versions 1.0 and
2.0, not available) were designed by the same author with the Amiga line's
needs specifically in mind: relatively slow floppy drives (Compared to hard
drives), so sparse read-head maneuvering was essential. Relatively small
memory, when compared with the amounts of memory required by most C compilers
(Lattice needs roughly 300k just to run, for example), so the code had to be
consise, pure, and use few variables. Expansion was always available; hard
drives, huge memory capacities, extra processors, ram drives -- so the system
had to be readily expandible and flexible enough to meet the requirements of
both a 512k, 1-drive machine and a 4-megabyte, 120-meg hard drive-driven
setup. And they were.
The problem was, Amigas can multi-task. So what is the rest of the
computer doing while a database runs around looking up records on one drive?
Nothing. Why not let it look up records on another drive? Fine... that works.
What about on the same drive... using, say, a ram disk, so there are no real
read-heads to worry about positioning? That would mean each relation would
have to support multi-user access... a requirement around which MetalBase
versions 3.0 and 3.1 focus. Not only can many terminals access many files at
once, but on multi-terminal systems, each terminal can work simultaneously on
any given file. Terminals can each use as many relations as a system will
allow, and each relation can be used by over one hundred users at once. The
code used to create MetaBase 3.X is completely compatible with the Unix )
operating system and all of its derivatives, so its inherent multi-user
ability places it in firm working footing on the most advanced systems on the
market.
Relations are designed by a user to match his/her exact requirements,
indicies placed as needed on single or composite fields, and records can be
added, retrieved, changed, and deleted as any C programmer so desires. The
interface is as simple as possible, very fast in execution, and provides a wide
range of error types for exact specification of problems. A user on any
terminal can choose to lock out other users from any number of relations, so
data that is about to be changed will not be read by others before changes
take place. Automatic temporary locks are placed on a relation which is about
to undergo a deletion or addition, thus delaying other users' access to files,
so that no data will be read until all indicies have been updated correctly.
This process is entirely system-driven; users never need worry about it at all.
If another user is adding a record to a relation, any terminal requesting a
record lookup will simply wait until the addition is complete before
proceeding. As records are deleted and added through normal use, the algorythms
used to update indicies automatically keep them at top operating speeds, so any
given relation's number of records can grow exponentially while causing only a
linear increase in look-up time. Any relation can contain over four billion
records (Nearly four billion more than most systems will ever need), and each
record's length can be as large as its system's memory can handle. In
perspective, MetalBase is infinitely expandible, while requiring very little of
the system on which it operates.
RELATION_DESIGN________________________________________________________________
A sample relation. Data Field # -> 1 2 3 4 5
is read by selecting one Record # _____ ___ ____ ___ ___________
record from the others by 1 |_____|___|____|___|___________|
various criteria, and 2 |_____|___|____|___|___________|
returning it to the user. 3 |Smith| 12| 114| A2|Houston, TX|
Record 3 (In this example-- 4 |-----|---|----|---|-----------|
actual MetalBase records need
no such numbering system), if returned, would be placed in a string
as "Smith| 12| 114| A2|Houston, TX|"
A relation is a collection of records, each record consisting of the same
number of fields, character strings whose length remains /\
/ \
../ \....METALBASE release version 3.1......................................
/ \
/ \ Written August 1989 through October 1990 by Huan-Ti
\ /
\ / Initially released December 10th 1990
\ /
\ /
\/
"And Calvin ate. And Food Lion went out of business. Amen."
--1st Calvin 4:8
WHY_METALBASE_?________________________________________________________________
The Amiga 500 multi-ta