All this talk about DataBases

Scott Kane scott at cdroo.com
Wed May 30 21:59:05 EDT 2007


From: "-= JB =-" <sundown at nwrain.net>

> One user said he was working with one million or more files so lets use 
> that as an example.  If I were to make a text file with one million card 
> ids in item
> one and the user name in item two and then put it into a variable and 
> perform a search for the id and
> retrieve the name:

Please keep in mind that my example is pretty extreme <g> and it's in text 
file format because it is stored originally on a *nix system which handles 
such volumes of text files far better than Windows does.  Even still I 
believe the original designer of the "text file database" in this instance 
was not only "lame" but had rocks in his head.

> 1.  What is the speed comparison to a database

A database with correctly optimized queries would handle most data lifting 
in under the 1 second mark - more according to how much data.  The example 
above would probably still have a bit of a delay, but implemented as Rev 
stacks and cards (for each record) it'd be at a minimum three to four 
seconds if not a great deal more.  This of course does not consider 
multi-user issues, how much RAM is consumed and how well queries are 
optimized which on some systems would make it difficult if not impossible to 
operate using the stack/card paradigm.  Even the design of the actual 
database plays a crucial role in efficiency.

> 2.  Is there a limit where this would not work or would be too slow in 
> Revolution and why.  If theR evolution search is too slow could a person
> write a faster search as an external.

The conclusion I've come to is that Rev can pretty much handle small data 
sets - beyond the 10,000 record mark (and I suspect the definition of how 
many and what type of fields are involved, what processes, calculations etc 
are in place) pretty much is the limit in practical terms.  For most small 
systems this might be fine, for more complex or larger systems a system 
(database) that is designed for the purpose is a better choice.

Scott 




More information about the use-livecode mailing list