home *** CD-ROM | disk | FTP | other *** search
/ Il CD di internet / CD.iso / SOURCE / CONTRIB / MBASE / MBASE51.TAR / mbase51 / tech / chapter.1 next >
Encoding:
Text File  |  1993-09-04  |  7.8 KB  |  181 lines

  1. Tech Chapter 1 - Relation format                                  MetalBase 5.1
  2. -------------------------------------------------------------------------------
  3.  
  4. MetalBase keeps track of all data in a single file (.REL extension), with
  5.    the exception of multi-length fields--data for those is stored in a second
  6.    file (.DAT extension).
  7.  
  8. The .REL file consists of a header containing descriptions of fields and
  9.    indices, followed by any number of fixed-length records.  Each record
  10.    actually consists of index information for a tuple, followed by a tuple's
  11.    record data (for each multi-length field, a pointer to an offset in the
  12.    .DAT file is stored).
  13.  
  14.  
  15. FIELD TYPES -------------------------------------------------------------------
  16.  
  17. Each field in a record is one of a number of intrinsic types; user-defined
  18.    types aren't supported (I was gonna put that in 4.1, but never bothered.
  19.    I'm glad I didn't now).  Valid field types are:
  20.  
  21.       Enum Name    Storage    Typedef From       Expected length
  22.       -----------  ---------  -----------------  ---------------
  23.       T_CHAR.......char [].......................any (fixed)**
  24.       T_SHORT......short.........................two bytes
  25.       T_USHORT.....ushort.....unsigned short.....two bytes
  26.       T_LONG.......long..........................four bytes
  27.       T_ULONG......ulong......unsigned long......four bytes
  28.       T_FLOAT......float.........................four bytes
  29.       T_DOUBLE.....double........................eight bytes
  30.       T_MONEY......double........................eight bytes
  31.       T_TIME.......mb_time....long...............four bytes
  32.       T_DATE.......mb_date....long...............four bytes
  33.       T_SERIAL.....long..........................four bytes
  34.       T_PHONE......mb_phone...struct mb_phone....varies (fixed)*
  35.       T_BYTE.......byte []....unsigned char []...any (fixed)**
  36.       T_MCHAR......mchar......struct mchar.......varies (fixed)*
  37.       T_MBYTE......mbyte......struct mbyte.......varies (fixed)*
  38.  
  39.     * the length of these fields depends on the structure-packing
  40.       algorithm used by the local compiler.
  41.  
  42.    ** the length of these fields is decided when the relation is
  43.       first built, and remains constant for each record.
  44.  
  45.  
  46. FIELD DESCRIPTIONS ------------------------------------------------------------
  47.  
  48.  
  49. T_MCHAR, T_MBYTE:
  50.    See the chapter on multi-length fields for an in-depth description of how
  51.    these fields are implemented.
  52.  
  53.  
  54. T_TIME and T_DATE:
  55.    These fields are stored as longs; information is stored in such an order
  56.    that more relevant information is stored in higher bits--in this way,
  57.    these fields can be sorted as if they were of type T_LONG and will
  58.    be sorted meaningfully even when parsed.
  59.  
  60.    Bits in time field:
  61.       00000000 hhhhhmmm mmmsssss suuuuuuu --h=hour,m=min,s=sec,u=microseconds
  62.  
  63.    Bits in date field:
  64.       00000000 00yyyyyy yyyyyyym mmmddddd --y=year,m=month,d=day
  65.  
  66.  
  67. T_MONEY:
  68.    Money is treated exactly as double, but is rounded to 2 decimal places
  69.    before being written or compared.  MetalBase releases prior to 5.1 used
  70.    the obvious algorithm for this--
  71.  
  72.             X = floor ( (long)(X * 100.0) ) / 100.0
  73.  
  74.    --but this doesn't work on most systems (it introduces huge floating-point
  75.    problems--try, for example, 34.16 in a T_MONEY field in 5.0).  Sad state of
  76.    the world.  The routine "double tomoney (double);" has been provided with
  77.    release 5.1 to correct this problem.
  78.  
  79.  
  80. T_SERIAL:
  81.    Serial fields are T_LONGs which are automatically filled before a call to
  82.    mb_add() or mb_add_q().  Calls to mb_upd() verify that the value of these
  83.    fields has not changed since the record being updated was first retrieved;
  84.    in this way, each record can be stamped with an indelible number.  The first
  85.    serial value assigned will be zero unless specified otherwise during
  86.    creation of the relation; it is incremented on each successive add, and
  87.    never decremented (even if a record is deleted).
  88.  
  89.  
  90. T_PHONE:
  91.    In MetalBase 5.0, phone number fields were stored as 20-character fields
  92.    which were formatted into a fixed form before being stored.  MetalBase 5.1,
  93.    and hopefully all later versions, use a structure consisting of three
  94.    shorts (area code, prefix and number) and one long (extension).
  95.  
  96.  
  97. T_BYTE:
  98.    These are used just about like char, save that if you index them, searches
  99.    won't stop at the first zero in the string (as they would for strings).
  100.    The routines hextostr() and strtohex() are used by MB_INPUT for data-entry
  101.    of byte fields.
  102.  
  103.  
  104. RELATION FORMAT ---------------------------------------------------------------
  105.  
  106.  
  107.    Pos  #/Bytes   Description
  108.  
  109.      0    1.......(char)51 : 5.1 signature
  110.      1    1.......Bit 1: Work flag -- set if relation is being updated
  111.                   Bit 2: fMulti    -- set if relation has multi-length fields
  112.                   Bit 3: fCorrupt  -- set if relation was found to be corrupt
  113.      2    4.......Number of unindexed records
  114.      6    4.......Pointer to fields' decriptions  => :A
  115.     10    4.......Pointer to indices' decriptions => :B
  116.     14    4.......Pointer to record 0             => :C
  117.     18    4.......Number of records
  118.     22    4.......Next serial field value
  119.     26    2.......Number of fields
  120.     28    2.......Number of indices
  121.     30    4*I.....Pointers to index-heading records (top record in each tree)
  122.  
  123.     A:    var*F...Fields' descriptions:
  124.                      byte    0 : Type (0-10, as listed above)
  125.                      bytes 1-2 : Size (short/ used only for char fields)
  126.                      bytes 3-? : Name (max len = 20, terminated by '|')
  127.  
  128.     B:    var*I...Indices' descriptions:
  129.                      byte    0 : Type (0-1, 0==nodups, 1==dups)
  130.                      bytes   1 : Number of fields in this index
  131.                      bytes 2-? : Name (max len = 20, terminated by ':')
  132.                            --- : Each field's sequential # (as short, 0-based)
  133.  
  134.     ?:    1.......(char)1 if encryption mask chosen yet; (char)0 if not
  135.     ?:    1.......Encryption mask; 0 indicates no encryption
  136.     ?:    126.....Unused since 5.0 (reserved space for later MB versions)
  137.     ?:    1.......Separator ('\n')
  138.  
  139.     C:    var*R...Records:
  140.                      13 bytes for each index: Index information
  141.                         Bytes  0-3 : Left-child (record #)
  142.                         Bytes  4-7 : Right-child (record #)
  143.                         Bytes 8-11 : Parent (record #)
  144.                         Byte    12 : Balance (';'=-2 '<'=-1 '='=0 '>'=1 '?'=2)
  145.                      recsize bytes : Record information (no field separators)
  146.                      1 byte separator ('\n')
  147.  
  148.     D:    var*R...Unindexed records:
  149.                      13 zeroes for each index, reserved for later indexing
  150.                      recsize bytes: Record information (no field separators)
  151.                      1 byte separator ('\n')
  152.  
  153.  
  154. Actual record information is stored as it looks in memory structures; thus,
  155.    relations will not be portable between machines unless the same structure-
  156.    packing algorithm is used on both systems.
  157.  
  158.  
  159. DATA-FILE FORMAT --------------------------------------------------------------
  160.  
  161.  
  162.    Pos  #/Bytes   Description
  163.  
  164.      0    1.......(char)51 : 5.1 signature
  165.      1    4.......offset of first free-space chain link
  166.  
  167. The chapter on multi-length fields describes the use of this file in more
  168.    detail.  Essentially, the .DAT file is a threaded heap, where only the
  169.    scattered blocks of free space are chained.  The byte-offsets of "used"
  170.    blocks are stored in the .REL file as pointers to data; however, the .DAT
  171.    file has no such link back to the appropriate record numbers in the .REL
  172.    file.  This was done for performance reasons, and doesn't really impact
  173.    the recovery of data within corrupt .REL/.DAT files (as you're basically
  174.    hosed anyway if things get bad).
  175.  
  176.    Pos  #/Bytes   Description
  177.  
  178.    n+0    4.......byte-offset of next link in the free chain, or 0L if at end
  179.    n+4    4.......number of bytes in this block, including these 8
  180.  
  181.