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