database

[Rob Cozens]

Hi Joanthan,

>What motivates you to create such a beast for free? Surely it took an
>enormous amount of work for you?

SDB was originally created in HyperTalk about 15 years ago.  I was working 
with a San Francisco winery supplier and Fresno State College professor of 
vitaculture on the forerunner of OenoLog.  We had purchased Answer 
Software's HyBase engine, a 4th generation db designed to back-end 
HyperCard, when Serge Grenier posted "Networking HyperCard Stacks" to the 
HyperCard Mailing List.

Seeing how simple it was (conceptually, if not in implementation) and 
desirous of (a) being able to modify and augment the db engine supporting 
our application and (b) freeing our project from royalty obligations, we 
abandoned HyBase and I scripted SDB's original version.

My reasons for making SDB open source and royalty-free are:

* I'm in the business applications software business, not the database/RAD 
tool business.

* It is my hope that others will use it and broaden the range of real-world 
testing and evaluation of SDB; thus strengthening my applications that rely 
upon it

* As with Serendipity Library in general, which was available to the 
HyperCard community B.R. (Before Revolution), SDB is my humble contribution 
to the xTalk community which has given much to me over the years.

I believe there is a real need for a db engine that integrates totally with 
Transcript and is free of non-essential baggage such as data typing & data 
dictionaries.  I believe that, like the original HyperCard, allowing people 
to use and poke around inside SDB at no risk (ie; cost) is a better way of 
gaining acceptance within the community than mounting a sales effort for a 
for-cost product.

>How does serendipity compare on speed to database programs written in
>C++?

I have done no head-to-head comparisons.  I will note that although SDB's 
design looks to maxiize processor efficiency, speed has never been the 
overriding goal.  Most db's I work with contain less than 20,000 records, 
and the speed I'm seeing (eg: retrieve one record out of 40,000 by key 
value in < 1 second on a G4 iMac wirh medium clock & RAM) is adequate.  If 
the C++ db engine is accessing a disk-based db, SDB has the advantage (and 
attendent RAM requirements on the server) of maintaining the entire db in 
RAM.  Finally, the index searching is currently basic binary, and could be 
redesigned to incorporate industrial-strength B-Tree indexing if the 
present performance isn't adequate.

Rob Cozens

"I must be the change I want to see in the world."

  -- Gandhi