Can Rev be used as server database?

[Rob Cozens]

Bernard, et al:

>
>I did take a look on your web site a few weeks or months ago for 
>some documentation on SDB.  I didn't find it,

No, it, like the page in my signature below, is not linked to the 
main website.  That's a spare time project, as the website is meant 
to promote OenoLog and there is nothing to promote to the majority of 
those on my mailing list until I can deploy on Windows.

>  >>
>the underlying MetaCard card-by-id index, which can be used directly by
>all SDB record manipulation calls except fileSDBRecord
><<
>
>I'm quite curious about this indexing.  Can you explain more about this?

The structure of an SDB database stack is:

	One index card with two fields
		Db Index
		Comments
	One record card for each record, with three fields
		Record Type
		Record Key
		Record Data

Record cards are filed in the stack in ascending order by Record Type 
& Record Key

The db index field has one line per record type with three items
	Record Type
	First Card #
	Last Card #

SDB's current index search handlers do a simple binary search on the 
Record Key field values of cards between First Card # & Last Card #. 
[If simple binary searching proves too slow for large dbs, the design 
can easily accommodate support for an industrial-strength B-tree 
index for each Record Type];

however,

* the fileSDBRecord command returns the id of the db card containing 
the record for future use by the client app.

* the sdbRecordIndex function returns paired lists of the keys & card 
ids of all, or a selective subset, of the records of the passed 
record type.

* all SDB record retrieval syntax recognizes the special Record Type, 
"0", which indicates the value passed as the key is actually the RR 
db stack card id #.

>   I think that one of the benefits of external file-based dbs is 
>that indices can be constructed over many different fields, leading 
>to speedier access paths for pertinent information.  If this could 
>be done in SDB then that would also be a big plus.

Except for a brief and unpleasant experience with Ingres in the mid 
1980s, I have worked exclusively with hierarchical business dbs.  To 
access records based on the value of a non-key field (eg: customers 
in zip code order) one defines a cross-reference record whose key is 
zipCode&customerId.  One can then use the customerId portion of the 
key to retrieve the actual record, or in SDB one could put a record 
(card) id field in the record retrieved via the "zipCust" cross 
reference.

So long as one can define the field cross reference paths at system 
design, this works admirably.  The drawback to hierarchical design 
only comes into play when there is a need to efficiently support AD 
HOC queries for which the index cross reference structure has not 
been optimized.

This discussion was initiated a little earlier than I planned because 
of this thread...I was planning to announce SDB C/S with the subject, 
"If You Don't Need 'Q', SDB Will Do".

>
>One major issue I would see with a stack-based database is that it 
>is memory-resident (if it is behaving as a normal stack).  Clearly 
>this would be very fast.  But what do you do about writing the 
>changes to disk?  Is the whole stack written out?  What happens in a 
>database that is bigger than available RAM?  Assuming enough RAM 
>(say 1 or 2gb), what happens when such a db is being written to disk.

Whether the server should save the db stack(s) to disk periodically 
or on command or not until shutdown is an issue I won't know the 
answer to until I have more operational experience with SDB C/S.  If 
one has UPS, the basic risk of not saving until shutdown is the risk 
of hardware failure.  Yes, the entire db would be copied from RAM to 
disk as with any RunRev Save, and db access would be blocked until 
the save was finished.

In a dedicated server environment, the server will be installed on a 
hardware platform with the disk & RAM space it needs.  OTOH, the RAM 
requirements of the client stacks are much less because they load 
only one record at a time.

>
>I'm very pleased to learn more about SDB.  I hope it has far more 
>potential than I have realised.

As I said in my initial response, I made SDB available tom the 
RunRev/MC community but have not touted it because I didn't know 
enough about the available alternatives.  The more I learn about the 
other alternatives, the more I appreciate SDB.
-- 
Rob Cozens
<http://www.oenolog.com/who.htm>

Vive R Revolution!