home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload / ShartewareOverload.cdr / database / mbase.zip / MBASE.DOX < prev    next >
Text File  |  1991-02-11  |  33KB  |  401 lines
  1.     /\
  2.    /  \
  3. ../    \....METALBASE release version 3.1......................................
  4.  /      \
  5. /        \  Written August 1989 through October 1990 by Huan-Ti
  6. \        /
  7.  \      /   Initially released December 10th 1990
  8.   \    /
  9.    \  /
  10.     \/
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.        "And Calvin ate.  And Food Lion went out of business.  Amen."
  19.  
  20.                                                    --1st Calvin 4:8
  21.  
  22.  
  23. WHY_METALBASE_?________________________________________________________________
  24.  
  25.     The Amiga 500 multi-tasks.  Wow.  It has great graphics.  Yeah.  Phenomenal
  26. sound.  Yippee.  It costs $500.  I bought one.
  27.     A DBase package costs more than the computer.  So does Paradox.  And
  28. Informix.  And almost every other database package on the market.  I didn't
  29. buy one.
  30.     But I needed a database for my system.  Anybody who's ever worked with a
  31. database knows they're addictive--code that's written without a flexible
  32. database backing it up lacks something.  And DBase wants $600 to put that
  33. something back into programs.  No thanks.
  34.     That's why MetalBase was written... its forerunners (versions 1.0 and
  35. 2.0, not available) were designed by the same author with the Amiga line's
  36. needs specifically in mind:  relatively slow floppy drives (Compared to hard
  37. drives), so sparse read-head maneuvering was essential.  Relatively small
  38. memory, when compared with the amounts of memory required by most C compilers
  39. (Lattice needs roughly 300k just to run, for example), so the code had to be
  40. consise, pure, and use few variables.  Expansion was always available; hard
  41. drives, huge memory capacities, extra processors, ram drives -- so the system
  42. had to be readily expandible and flexible enough to meet the requirements of
  43. both a 512k, 1-drive machine and a 4-megabyte, 120-meg hard drive-driven
  44. setup.  And they were.
  45.     The problem was, Amigas can multi-task.  So what is the rest of the
  46. computer doing while a database runs around looking up records on one drive?
  47. Nothing.  Why not let it look up records on another drive?  Fine... that works.
  48. What about on the same drive... using, say, a ram disk, so there are no real
  49. read-heads to worry about positioning?  That would mean each relation would
  50. have to support multi-user access... a requirement around which MetalBase
  51. versions 3.0 and 3.1 focus.  Not only can many terminals access many files at
  52. once, but on multi-terminal systems, each terminal can work simultaneously on
  53. any given file.  Terminals can each use as many relations as a system will
  54. allow, and each relation can be used by over one hundred users at once.  The
  55. code used to create MetaBase 3.X is completely compatible with the Unix )
  56. operating system and all of its derivatives, so its inherent multi-user
  57. ability places it in firm working footing on the most advanced systems on the
  58. market.
  59.     Relations are designed by a user to match his/her exact requirements,
  60. indicies placed as needed on single or composite fields, and records can be
  61. added, retrieved, changed, and deleted as any C programmer so desires.  The
  62. interface is as simple as possible, very fast in execution, and provides a wide
  63. range of error types for exact specification of problems.  A user on any
  64. terminal can choose to lock out other users from any number of relations, so
  65. data that is about to be changed will not be read by others before changes
  66. take place.  Automatic temporary locks are placed on a relation which is about
  67. to undergo a deletion or addition, thus delaying other users' access to files,
  68. so that no data will be read until all indicies have been updated correctly.
  69. This process is entirely system-driven; users never need worry about it at all.
  70. If another user is adding a record to a relation, any terminal requesting a
  71. record lookup will simply wait until the addition is complete before
  72. proceeding. As records are deleted and added through normal use, the algorythms
  73. used to update indicies automatically keep them at top operating speeds, so any
  74. given relation's number of records can grow exponentially while causing only a
  75. linear increase in look-up time.  Any relation can contain over four billion
  76. records (Nearly four billion more than most systems will ever need), and each
  77. record's length can be as large as its system's memory can handle.  In
  78. perspective, MetalBase is infinitely expandible, while requiring very little of
  79. the system on which it operates.
  80.  
  81.  
  82. RELATION_DESIGN________________________________________________________________
  83.  
  84.         A sample relation.  Data      Field # ->  1    2   3    4       5
  85.         is read by selecting one     Record #   _____ ___ ____ ___ ___________
  86.         record from the others by          1   |_____|___|____|___|___________|
  87.         various criteria, and              2   |_____|___|____|___|___________|
  88.         returning it to the user.          3   |Smith| 12| 114| A2|Houston, TX|
  89.         Record 3 (In this example--        4   |-----|---|----|---|-----------|
  90.         actual MetalBase records need
  91.         no such numbering system), if returned, would be placed in a string
  92.         as "Smith| 12| 114| A2|Houston, TX|"
  93.  
  94.     A relation is a collection of records, each record consisting of the same
  95. number of fields, character strings whose length remains    /\
  96.    /  \
  97. ../    \....METALBASE release version 3.1......................................
  98.  /      \
  99. /        \  Written August 1989 through October 1990 by Huan-Ti
  100. \        /
  101.  \      /   Initially released December 10th 1990
  102.   \    /
  103.    \  /
  104.     \/
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.        "And Calvin ate.  And Food Lion went out of business.  Amen."
  113.  
  114.                                                    --1st Calvin 4:8
  115.  
  116.  
  117. WHY_METALBASE_?________________________________________________________________
  118.  
  119.     The Amiga 500 multi-tasks.  Wow.  It has great graphics.  Yeah.  Phenomenal
  120. sound.  Yippee.  It costs $500.  I bought one.
  121.     A DBase package costs more than the computer.  So does Paradox.  And
  122. Informix.  And almost every other database package on the market.  I didn't
  123. buy one.
  124.     But I needed a database for my system.  Anybody who's ever worked with a
  125. database knows they're addictive--code that's written without a flexible
  126. database backing it up lacks something.  And DBase wants $600 to put that
  127. something back into programs.  No thanks.
  128.     That's why MetalBase was written... its forerunners (versions 1.0 and
  129. 2.0, not available) were designed by the same author with the Amiga line's
  130. needs specifically in mind:  relatively slow floppy drives (Compared to hard
  131. drives), so sparse read-head maneuvering was essential.  Relatively small
  132. memory, when compared with the amounts of memory required by most C compilers
  133. (Lattice needs roughly 300k just to run, for example), so the code had to be
  134. consise, pure, and use few variables.  Expansion was always available; hard
  135. drives, huge memory capacities, extra processors, ram drives -- so the system
  136. had to be readily expandible and flexible enough to meet the requirements of
  137. both a 512k, 1-drive machine and a 4-megabyte, 120-meg hard drive-driven
  138. setup.  And they were.
  139.     The problem was, Amigas can multi-task.  So what is the rest of the
  140. computer doing while a database runs around looking up records on one drive?
  141. Nothing.  Why not let it look up records on another drive?  Fine... that works.
  142. What about on the same drive... using, say, a ram disk, so there are no real
  143. read-heads to worry about positioning?  That would mean each relation would
  144. have to support multi-user access... a requirement around which MetalBase
  145. versions 3.0 and 3.1 focus.  Not only can many terminals access many files at
  146. once, but on multi-terminal systems, each terminal can work simultaneously on
  147. any given file.  Terminals can each use as many relations as a system will
  148. allow, and each relation can be used by over one hundred users at once.  The
  149. code used to create MetaBase 3.X is completely compatible with the Unix )
  150. operating system and all of its derivatives, so its inherent multi-user
  151. ability places it in firm working footing on the most advanced systems on the
  152. market.
  153.     Relations are designed by a user to match his/her exact requirements,
  154. indicies placed as needed on single or composite fields, and records can be
  155. added, retrieved, changed, and deleted as any C programmer so desires.  The
  156. interface is as simple as possible, very fast in execution, and provides a wide
  157. range of error types for exact specification of problems.  A user on any
  158. terminal can choose to lock out other users from any number of relations, so
  159. data that is about to be changed will not be read by others before changes
  160. take place.  Automatic temporary locks are placed on a relation which is about
  161. to undergo a deletion or addition, thus delaying other users' access to files,
  162. so that no data will be read until all indicies have been updated correctly.
  163. This process is entirely system-driven; users never need worry about it at all.
  164. If another user is adding a record to a relation, any terminal requesting a
  165. record lookup will simply wait until the addition is complete before
  166. proceeding. As records are deleted and added through normal use, the algorythms
  167. used to update indicies automatically keep them at top operating speeds, so any
  168. given relation's number of records can grow exponentially while causing only a
  169. linear increase in look-up time.  Any relation can contain over four billion
  170. records (Nearly four billion more than most systems will ever need), and each
  171. record's length can be as large as its system's memory can handle.  In
  172. perspective, MetalBase is infinitely expandible, while requiring very little of
  173. the system on which it operates.
  174.  
  175.  
  176. RELATION_DESIGN________________________________________________________________
  177.  
  178.         A sample relation.  Data      Field # ->  1    2   3    4       5
  179.         is read by selecting one     Record #   _____ ___ ____ ___ ___________
  180.         record from the others by          1   |_____|___|____|___|___________|
  181.         various criteria, and              2   |_____|___|____|___|___________|
  182.         returning it to the user.          3   |Smith| 12| 114| A2|Houston, TX|
  183.         Record 3 (In this example--        4   |-----|---|----|---|-----------|
  184.         actual MetalBase records need
  185.         no such numbering system), if returned, would be placed in a string
  186.         as "Smith| 12| 114| A2|Houston, TX|"
  187.  
  188.     A relation is a collection of records, each record consisting of the same
  189. number of fields, character strings whose length remains    /\
  190.    /  \
  191. ../    \....METALBASE release version 3.1......................................
  192.  /      \
  193. /        \  Written August 1989 through October 1990 by Huan-Ti
  194. \        /
  195.  \      /   Initially released December 10th 1990
  196.   \    /
  197.    \  /
  198.     \/
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.        "And Calvin ate.  And Food Lion went out of business.  Amen."
  207.  
  208.                                                    --1st Calvin 4:8
  209.  
  210.  
  211. WHY_METALBASE_?________________________________________________________________
  212.  
  213.     The Amiga 500 multi-tasks.  Wow.  It has great graphics.  Yeah.  Phenomenal
  214. sound.  Yippee.  It costs $500.  I bought one.
  215.     A DBase package costs more than the computer.  So does Paradox.  And
  216. Informix.  And almost every other database package on the market.  I didn't
  217. buy one.
  218.     But I needed a database for my system.  Anybody who's ever worked with a
  219. database knows they're addictive--code that's written without a flexible
  220. database backing it up lacks something.  And DBase wants $600 to put that
  221. something back into programs.  No thanks.
  222.     That's why MetalBase was written... its forerunners (versions 1.0 and
  223. 2.0, not available) were designed by the same author with the Amiga line's
  224. needs specifically in mind:  relatively slow floppy drives (Compared to hard
  225. drives), so sparse read-head maneuvering was essential.  Relatively small
  226. memory, when compared with the amounts of memory required by most C compilers
  227. (Lattice needs roughly 300k just to run, for example), so the code had to be
  228. consise, pure, and use few variables.  Expansion was always available; hard
  229. drives, huge memory capacities, extra processors, ram drives -- so the system
  230. had to be readily expandible and flexible enough to meet the requirements of
  231. both a 512k, 1-drive machine and a 4-megabyte, 120-meg hard drive-driven
  232. setup.  And they were.
  233.     The problem was, Amigas can multi-task.  So what is the rest of the
  234. computer doing while a database runs around looking up records on one drive?
  235. Nothing.  Why not let it look up records on another drive?  Fine... that works.
  236. What about on the same drive... using, say, a ram disk, so there are no real
  237. read-heads to worry about positioning?  That would mean each relation would
  238. have to support multi-user access... a requirement around which MetalBase
  239. versions 3.0 and 3.1 focus.  Not only can many terminals access many files at
  240. once, but on multi-terminal systems, each terminal can work simultaneously on
  241. any given file.  Terminals can each use as many relations as a system will
  242. allow, and each relation can be used by over one hundred users at once.  The
  243. code used to create MetaBase 3.X is completely compatible with the Unix )
  244. operating system and all of its derivatives, so its inherent multi-user
  245. ability places it in firm working footing on the most advanced systems on the
  246. market.
  247.     Relations are designed by a user to match his/her exact requirements,
  248. indicies placed as needed on single or composite fields, and records can be
  249. added, retrieved, changed, and deleted as any C programmer so desires.  The
  250. interface is as simple as possible, very fast in execution, and provides a wide
  251. range of error types for exact specification of problems.  A user on any
  252. terminal can choose to lock out other users from any number of relations, so
  253. data that is about to be changed will not be read by others before changes
  254. take place.  Automatic temporary locks are placed on a relation which is about
  255. to undergo a deletion or addition, thus delaying other users' access to files,
  256. so that no data will be read until all indicies have been updated correctly.
  257. This process is entirely system-driven; users never need worry about it at all.
  258. If another user is adding a record to a relation, any terminal requesting a
  259. record lookup will simply wait until the addition is complete before
  260. proceeding. As records are deleted and added through normal use, the algorythms
  261. used to update indicies automatically keep them at top operating speeds, so any
  262. given relation's number of records can grow exponentially while causing only a
  263. linear increase in look-up time.  Any relation can contain over four billion
  264. records (Nearly four billion more than most systems will ever need), and each
  265. record's length can be as large as its system's memory can handle.  In
  266. perspective, MetalBase is infinitely expandible, while requiring very little of
  267. the system on which it operates.
  268.  
  269.  
  270. RELATION_DESIGN________________________________________________________________
  271.  
  272.         A sample relation.  Data      Field # ->  1    2   3    4       5
  273.         is read by selecting one     Record #   _____ ___ ____ ___ ___________
  274.         record from the others by          1   |_____|___|____|___|___________|
  275.         various criteria, and              2   |_____|___|____|___|___________|
  276.         returning it to the user.          3   |Smith| 12| 114| A2|Houston, TX|
  277.         Record 3 (In this example--        4   |-----|---|----|---|-----------|
  278.         actual MetalBase records need
  279.         no such numbering system), if returned, would be placed in a string
  280.         as "Smith| 12| 114| A2|Houston, TX|"
  281.  
  282.     A relation is a collection of records, each record consisting of the same
  283. number of fields, character strings whose length remains    /\
  284.    /  \
  285. ../    \....METALBASE release version 3.1......................................
  286.  /      \
  287. /        \  Written August 1989 through October 1990 by Huan-Ti
  288. \        /
  289.  \      /   Initially released December 10th 1990
  290.   \    /
  291.    \  /
  292.     \/
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.        "And Calvin ate.  And Food Lion went out of business.  Amen."
  301.  
  302.                                                    --1st Calvin 4:8
  303.  
  304.  
  305. WHY_METALBASE_?________________________________________________________________
  306.  
  307.     The Amiga 500 multi-tasks.  Wow.  It has great graphics.  Yeah.  Phenomenal
  308. sound.  Yippee.  It costs $500.  I bought one.
  309.     A DBase package costs more than the computer.  So does Paradox.  And
  310. Informix.  And almost every other database package on the market.  I didn't
  311. buy one.
  312.     But I needed a database for my system.  Anybody who's ever worked with a
  313. database knows they're addictive--code that's written without a flexible
  314. database backing it up lacks something.  And DBase wants $600 to put that
  315. something back into programs.  No thanks.
  316.     That's why MetalBase was written... its forerunners (versions 1.0 and
  317. 2.0, not available) were designed by the same author with the Amiga line's
  318. needs specifically in mind:  relatively slow floppy drives (Compared to hard
  319. drives), so sparse read-head maneuvering was essential.  Relatively small
  320. memory, when compared with the amounts of memory required by most C compilers
  321. (Lattice needs roughly 300k just to run, for example), so the code had to be
  322. consise, pure, and use few variables.  Expansion was always available; hard
  323. drives, huge memory capacities, extra processors, ram drives -- so the system
  324. had to be readily expandible and flexible enough to meet the requirements of
  325. both a 512k, 1-drive machine and a 4-megabyte, 120-meg hard drive-driven
  326. setup.  And they were.
  327.     The problem was, Amigas can multi-task.  So what is the rest of the
  328. computer doing while a database runs around looking up records on one drive?
  329. Nothing.  Why not let it look up records on another drive?  Fine... that works.
  330. What about on the same drive... using, say, a ram disk, so there are no real
  331. read-heads to worry about positioning?  That would mean each relation would
  332. have to support multi-user access... a requirement around which MetalBase
  333. versions 3.0 and 3.1 focus.  Not only can many terminals access many files at
  334. once, but on multi-terminal systems, each terminal can work simultaneously on
  335. any given file.  Terminals can each use as many relations as a system will
  336. allow, and each relation can be used by over one hundred users at once.  The
  337. code used to create MetaBase 3.X is completely compatible with the Unix )
  338. operating system and all of its derivatives, so its inherent multi-user
  339. ability places it in firm working footing on the most advanced systems on the
  340. market.
  341.     Relations are designed by a user to match his/her exact requirements,
  342. indicies placed as needed on single or composite fields, and records can be
  343. added, retrieved, changed, and deleted as any C programmer so desires.  The
  344. interface is as simple as possible, very fast in execution, and provides a wide
  345. range of error types for exact specification of problems.  A user on any
  346. terminal can choose to lock out other users from any number of relations, so
  347. data that is about to be changed will not be read by others before changes
  348. take place.  Automatic temporary locks are placed on a relation which is about
  349. to undergo a deletion or addition, thus delaying other users' access to files,
  350. so that no data will be read until all indicies have been updated correctly.
  351. This process is entirely system-driven; users never need worry about it at all.
  352. If another user is adding a record to a relation, any terminal requesting a
  353. record lookup will simply wait until the addition is complete before
  354. proceeding. As records are deleted and added through normal use, the algorythms
  355. used to update indicies automatically keep them at top operating speeds, so any
  356. given relation's number of records can grow exponentially while causing only a
  357. linear increase in look-up time.  Any relation can contain over four billion
  358. records (Nearly four billion more than most systems will ever need), and each
  359. record's length can be as large as its system's memory can handle.  In
  360. perspective, MetalBase is infinitely expandible, while requiring very little of
  361. the system on which it operates.
  362.  
  363.  
  364. RELATION_DESIGN________________________________________________________________
  365.  
  366.         A sample relation.  Data      Field # ->  1    2   3    4       5
  367.         is read by selecting one     Record #   _____ ___ ____ ___ ___________
  368.         record from the others by          1   |_____|___|____|___|___________|
  369.         various criteria, and              2   |_____|___|____|___|___________|
  370.         returning it to the user.          3   |Smith| 12| 114| A2|Houston, TX|
  371.         Record 3 (In this example--        4   |-----|---|----|---|-----------|
  372.         actual MetalBase records need
  373.         no such numbering system), if returned, would be placed in a string
  374.         as "Smith| 12| 114| A2|Houston, TX|"
  375.  
  376.     A relation is a collection of records, each record consisting of the same
  377. number of fields, character strings whose length remains    /\
  378.    /  \
  379. ../    \....METALBASE release version 3.1......................................
  380.  /      \
  381. /        \  Written August 1989 through October 1990 by Huan-Ti
  382. \        /
  383.  \      /   Initially released December 10th 1990
  384.   \    /
  385.    \  /
  386.     \/
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.        "And Calvin ate.  And Food Lion went out of business.  Amen."
  395.  
  396.                                                    --1st Calvin 4:8
  397.  
  398.  
  399. WHY_METALBASE_?________________________________________________________________
  400.  
  401.     The Amiga 500 multi-ta