Any information on this would be appreciated for an article on database use that I am working on.
I gathered some additional thoughts from private posts to send you off-list; but I no longer have your original message or private eAddress:
Date: Wed, 25 Jun 2003 09:13:25 -0700 To: "Tuviah Snyder" <[EMAIL PROTECTED]> From: Rob Cozens <[EMAIL PROTECTED]> Subject: A Few More Thoughts Re SDB & SQL
Hi Tuviah,
I'm so pleased to get to meet you last night. I hope to work closely with you re any issues, questions, or problems RunRev might have as I deliver Client/Server SDB and promote it as an alternative to SQL & Valentina, and I think it helps in those situations to have met face-to-face.
Here are the thoughts I shared with Jan:
>>>if you're looking to cooperate on adding SQL to SDB, I'd be happy to volunteer
As of yesterday, I have a real dilemma here, Jan.
On the one hand, it would certainly promote SDB's acceptance & use by the RunRev community ON ONE LEVEL (back to that later), but on the other hand:
1. I just got reacquainted with relational syntax for the first time since working with Ingress in 1983 & 84, and I HATE IT.
A. In my estimation, at least 85% of SQL syntax has to do with query functions that at least 95% of my clients don't need or want.
B. In my estimation, 99% of SQL data typing is non-sequitur for xTalks that deal primarily with strings.
C. In my estimation, 60-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.
2. You can give me a better idea when you get time to look under the hood; but I'm not sure SDB design lends itself to "relationalization", and more importantly...
3. I feel like there enough SQL alternatives already available to RunRev developers (albeit none in Transcript). I would like SDB to be seen as an alternative to SQL, not just another SQL wannabe.
I am anxious to continue this discussion once you are more familiar with SDB's design, capabilities, & syntax. At that point I would ask you to step back from your preconceptions as to db standards, ask yourself "exactly what data storage & retrieval capabilities do I need" and "what is good and bad about the way SDB addresses my needs", leaving SQL compatibility a non-issue.
To be continued.... <<<
The following was sent to Paul Looney & Richard Gaskin, subject "My Usability Chart", 18 June, 2003
>>> Feel free to add Valentina.
* Server Installation:
On Mac OS X, MySQL Server must be installed (& maintained) in the Unix root via the Terminal application using Unix command line syntax. All server files & code must be in specific directory locations.
SDB Server can be dragged to any folder that the O/S allows applications to reside in. SDB databases can be located in any folder(s) accessible to the server.
* 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.
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 oridinal 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 entire record is processed by the server. [Tuviah, I meant when the input is sent to 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) [a 43 MB, 43,043-record db is the largest tested as of 16 Mar 2004]; 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 all 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.
I'll probably think of some additions later; but I'll focus elsewhere for a few hours.
<<<
--
Rob Cozens <http://www.oenolog.net/who.htm>
Vive R Revolution!
And as of yesterday, SDB includes RAD capabilities supporting creation of database applications without scripting.
--
Rob Cozens CCW, Serendipity Software Company http://www.oenolog.net/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
