Database Experience

[Rob Cozens]

John,

>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" <tuviah at runrev.com>
>From: Rob Cozens <rcozens at pon.net>
>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)