Hi Gabriele,

>PROJECT NAME: dbms3.r (temporary)
>
>PURPOSE:
>
>writing a small and simple relational database management system
>in REBOL, for use with applications that don't need a full blown
>separate DBMS such as MySQL. With respect to dbms.r, it will be
>more efficient in the data storage to be usable with much more
>rows per table, and possibly will have a more powerful/abstracted
>interface.

Here are some of my design thoughts at the binary DB level
before getting into the row/col level functions.  

I am assuming (dangerous I know) that binary storage is an option 
at all.  If you want a text based storage system then ignore this input. :-)

I am concerned in my ignorance about your comment on REBOL not
being able to seek "easily" on direct ports.  Could you expand on this 
for me?  It may be that REBOL just can't do the block oriented binary 
DB that I am envisioning - at this version anyway.

Please note - these design notes are just that.  They only represent some
effort at considering the requirements of a binary DB storage system.  It
is based on some C work I did for a handheld computer I was programming
for a couple of years ago.  In the end we kept our application data in csv 
style text files for simplicity so none of this made it past "design".

1.  Every database has a leading "Master" block.  This block contains
structured information about the database so it can be used properly.

Master_Block

  Type
  Version
  Special Key
  Set of Flags
  Block Size
  Extend Count
  Free Block Count
  Free Block Root
  Chain Block Root

2.  The rest of the database are "Normal" blocks of different types.  Each
of these blocks contains a standard fixed length "Header" with structured
information about the block.  After the header is the data storage area.

Block_Header

  Key  (DB location by offset based on fixed block size)
  Type
  Datatype
  Set of Flags
  Next Block Key
  Previous Block Key

>From these basic pieces everything else is built.  Each block in the database
can belong in a doubly linked list style structure to provide a "series" of blocks.
Special types of "Named" series such as an Index or Hash Table can be built
by registering them with the list of chains stored in the root chain block.

The block manager is only responsible for the following activities:

1.  Creating, opening, and closing the binary file.
2.  Initilizing and managing the master block data.
3.  Providing functions to manage named chains.
4.  Reading and writing blocks.
5.  Managing the free block chain for allocation/reuse.
6.  Traversing the block chains.

At only a slightly higher level you would make use of the block chain
structures to fill purposes such as defining a table to storing data and
indexing it.  Above that is where you would start interacting with the
database as rows/cols or whatever it was designed for.

I am leaving out lots of details for brevity and at this point want to
follow Gabriele's lead and stop here and wait for reactions.  I don't
want to run off in a direction no one is interested in or distract from
the main thread any more than I have so far without some list input.

Thanks for listening, Rod.

Rod Gaither
Oak Ridge, NC - USA
[EMAIL PROTECTED]



-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.

Reply via email to