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