Can Rev be used as server database?

[Rob Cozens]

Hi Bernard,

>Furthermore, there is the whole issue of locking for writes to the 
>database.  I'm not sure if the Serendipity db has any locking 
>mechanism.

The single-user version of SDB currently available at my ftp site 
does not; the Client/Server version now being alpha tested does.
>
>Without some kind of locking or versioning mechanism, I don't see 
>how one can have a multiuser database.

One could use HyperCard's "only the first one to open a stack can 
modify it" approach; however, in general I agree.

>
>To my way of thinking, it is better to exploit some of the freely 
>available, tried and tested relational databases.

I have remained fairly mute on this issue because I had no real 
experience with the RunRev db alternatives: I created SDB close to a 
decade ago, and there was no doubt in my mind I would use it for 
OenoLog and my other personal projects.

I have since had to explore MySQL in some depth for a project I am 
working on for someone else...{who is now taking a serious look at 
SDB). The more I work with MySQL, the more I'm convinced that, for 
the x-Talks community, SDB blows SQL away in terms of usability:

* In my estimation, 99% of SQL data typing is non-sequitur for xTalks 
that deal primarily with strings.

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

* In my estimation, at least 85% of SQL syntax has to do with query 
functions that at least 95% of my clients/applications don't need or 
want.

* Server Installation:

MySQL Server must be installed (& maintained) on Mac OS X in the Unix 
root via the Terminal application using Unix command line syntax. 
The server will not run on Ma OS 9.

SDB Server can be dragged to any folder that the O/S allows 
applications to reside in.

* Cross-Platform Installation:

MySQL requires platform-specific drivers in the form of extensions, DLLs, etc.

SDB runs as native Transcript in one version on any platform 
Revolution supports.

* Security:

MySQL requires password security & user identification before it can 
be used, and supports limited access to the field level.

SDB supports edit & browse passwords, but requires NO password 
protection or user identification for use.  [User id can be supported 
by defining a user record in the data dictionary and scripting 
support for same.]

* Data Dictionary:

MySQL requires creation of a data dictionary record (table 
definition) for each record type before records can be filed.  That 
table definition must name & type every field (column) in the table. 
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 cannot believe there is not some simple syntax 
for this; but no one has clued me in as to what it is.]

SDB's data dictionary is optional.  The SDB server can deal with the 
record without knowing its structure and the user can reference 
individual fields by number instead of creating data name entries in 
the Dictionary.

* User Input Editing:

MySQL can only check user input for its specific edit types, and then 
only when the record is processed by the server.  Most of the edit 
types are meaningless when working in Transcript.

SDB Client's frontScript can filter each keystroke based on data 
dictionary edit criteria and provide immediate feedback to the user. 
The Dictionary entry can also specify a Transcript edit handler & 
formatting instructions to be applied to the user's input on 
closeField.

* Access to Source Code:

MySQL is open source...in C & C++.  Anyone want to mess with that?

SDB is open source...in Transcript.

* Stability of Engine:

MySQL has been in use by thousands of users for many years and is 
proven with gigabyte+ databases.

SDB has been used by a handful of users for many years with 
single-user db's generally < 1MB (or 5K records); HOWEVER, the 
underlying MetaCard card-by-id index, which can be used directly by 
all SDB record manipulation calls except fileSDBRecord, has been used 
by thousands of users for many years and is proven for whatever MC/RR 
stack contains the most cards.

* Utility of features:

The MySQL syntax is designed to facilitate AD HOC db queries from 
many programming environments, and places the overhead for filtering, 
sorting, & formatting data on the server.  It supports the data types 
present in traditional non-xTalks dbs.  The majority of MySQL's data 
types and server data manipulation are not needed, as data in fields 
or passed as arguments is in string format and data manipulation is 
better handled in Transcript.

SDB syntax is designed for fast, efficient storage & retrieval of 
string data for RunRev & MC specifically, using preset (as opposed to 
ad hoc) index paths.  It supports filtering, sorting, and formatting 
at the Client end in Transcript syntax.

* DB Editing:

MySQL stores data in files that are inaccessible & undecipherable to 
the programmer & system administrator.

SDB stores data in string format that can be understood & directly 
edited by the programmer & system administrator.

-- 

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)