Can Rev be used as server database?

[revolution at knowledgeworks.plus.com]

Hi Rob,

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, and guessed that you thought that anyone who was really interested would take a look at the code, since you kindly make it available for us to read.  Sorry, I was too lazy, and was just looking for an overview of what it was about.  This email gives me some more idea concerning that, so thank you.

I wasn't meaning to criticize or pour cold water on this project.  I was more responding to Alex's suggestions about Zope and ZODB.  I think that the kind of effort involved in producing something like that would be immense.

However, let me respond to some of your other points:

>>
* In my estimation, 99% of SQL data typing is non-sequitur for xTalks 
that deal primarily with strings.
<<
I agree with this.  I pointed out when I posted on the existence of SQLite that all data is stored as strings, and that this would probably be amenable to xTalkers.  However, there are good reasons for tightly controlling the datatypes in backend databases, especially if multiple programmers/programs/languages are going to be sharing this data.

>>
* In my estimation, 80% of SQLs parsing, sorting, and formatting 
functions can be handled just as easily in Transcript at the client 
end; thus reducing the load on the server.
<<
Agreed, and this is probably the case with many languages.  However, depending on the data sizes and speeds of network connections, one really may not want to shunt huge amounts of data around when it can be pre-processed by the backend before it is sent across the network.  In certain circomstances this may lead to a reduction in dataset size. Furthermore it may well be that one wants the potential to have it processed on really beefed up hardware.

>>
MySQL Server must be installed (& maintained)
<<
Again, there are freely-available multi-platform, embeddable databases such as Firebird and SQLite.  They are virtually maintenance free.

>>
* Security:
<<
... is a boon or a nuisance, depending on the circumstances :-)

>>
If you have 100 fields, you must name & type all 100.  So far as I 
can see there is no shortcut to specify all fields in one record in a 
table ("*" specifies all records in the table); so to select one 
record with 100 fields one must specify each field by name in the 
SELECT command.
<<
I don't understand all of this.  I understand that (generally) there is no way to define a series of fields in a batch process (although some Object-Relational mapping tools could do this).  With regard to selecting the data from these fields in SQL then "select * from myTable" will do that.  I'm sure you mean something else than this though.  [I think your subsequent post about this has probably cleared this up.]

>>
* User Input Editing:
<<
Agreed.  It does seem rather pointless defining the valid datatype in the back end and then having to duplicate validation rules in all front end apps.  I'm working on mechanisms to make this a uniform process with a single point of definition.

>>
SDB is open source...in Transcript.
<<
A big plus :-)

>>
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?  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.

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.

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

Regards
Bernard