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 DataRecord 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! _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
