database

Lynch, Jonathan bnz2 at cdc.gov
Mon Oct 24 12:00:45 EDT 2005


Very cool!

More of that community spirit stuff that I find so admirable.

If you keep the entire DB in RAM, then do you have to save the entire DB
when you do a save, or can you save just one record?

-----Original Message-----
From: use-revolution-bounces at lists.runrev.com
[mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of Rob Cozens
Sent: Monday, October 24, 2005 11:36 AM
To: How to use Revolution
Subject: RE: database

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 

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list